Security Posture Pack

No. Keys are software keys held by the service. There is no HSM and no claim of one. A provider interface exists so that AWS KMS, Azure Key Vault, Google Cloud KMS or a PKCS#11 HSM can be added without changing what an evidence pack means, because packs reference a key identifier rather than key material. No such provider is configured today, and the status command reports hardware_backed as false.

No. EcoKure has one director, who requests, approves and performs every custody operation. This is a genuine gap and is recorded as one. The compensating control is that every operation writes an immutable audit event naming the actor, and the trail can be given to a customer for independent review.

Not for the API, which is machine to machine and uses keys. SAML or OIDC for the administrative interface is not built.

No formal review cycle exists. With one administrator there is nothing to review today, but this will not remain true and it is not presented as a control.

Application logs and platform health checks exist. There is no security information and event management system, no alerting on anomalous authentication, and no on-call rotation.

No RTO or RPO is committed. Publishing a number that has never been tested would be worse than saying this.

No penetration test has been performed and no independent security assurance engagement has been completed. An external engineer conducted an architecture and code audit of the DTL system, which is useful but is neither of those things, and it did not cover concurrency or load. Concurrency was subsequently tested by us, which found and fixed real defects, and that is our own testing, not third party validation.

None. EcoKure holds no SOC 2 report, no ISO 27001 certification, no HIPAA attestation and no FedRAMP authorisation, and is not in an active certification process for any of them. A customer requiring certified vendors should treat this as disqualifying rather than as a roadmap item.

EcoKure supplies deterministic verification gates. A gate takes a proposed output or action and returns an allow or refuse decision with a machine checkable certificate. The company is pre-revenue with one director. Nothing in this pack should be read as describing a large security organisation.

Internal benchmarks are never described as independent validation. Benchmark procedure requires that a result counts only when the unmodified harness is the authority and an integrity scan is clean, and where an earlier internal result failed that bar the finding was written down rather than removed. A reviewer should read the honest-loop handoffs cited here as the record of what was rejected, not only of what was kept.

Yes. The gates are deterministic and local, the keystore is a directory on disk, and the attestation chain is a local SQLite database. A test asserts that the entire key custody lifecycle completes with all socket connections blocked, so a dependency on a network call would fail CI rather than surprise an air-gapped customer.

Offline, on-premises and private cloud are supported by the same container and require no outbound connectivity. Public multi-tenant SaaS is what EcoKure operates today. On-premises has been engineered for but has not yet been installed by a customer, so it is proven by design and tests rather than by an operating reference installation.

SaaS: EcoKure operates the application, the keystore, the attestation chain and the hosting configuration. The customer owns their API key handling, who they grant access to, and their retention of issued evidence packs. On-premises: the customer owns the host, the operating system, backups, network controls, database encryption and physical security. EcoKure supplies the software, the custody procedures and the verification tooling.

Three. Signing authority never leaves the host and no interface returns private key material. Verification material is published freely, because a public key is what lets a customer check our work without being able to forge it. The customer side holds evidence packs, which reference a key identifier and never key material, and can be verified with no connection back to us.

Yes, and this is the central design property. Every verdict is appended to a hash chain whose head is signed, and any holder of a pack plus the published public key can recompute the chain and check the signature offline.

The content submitted for verification, for the duration of the call; the resulting verdict; and usage counters. Tenant and entitlement records hold an organisation name, a plan and counters.

The transparency chain does not store the content of a verification, or even a recomputable hash of it. It stores a hiding commitment over the certificate hash with a 128 bit nonce, because the gates are open source and a raw hash over a low entropy input, a drug and a dose and a weight for instance, would be brute forceable by anyone reading the public log.

Submitted content is processed in memory and is not persisted by the gate. Persisted state is the attestation chain, tenant and entitlement records, and the keystore. In a customer-hosted deployment none of this leaves their infrastructure.

A tenant is a first class object. Entitlements belong to a tenant and API keys are bound to both, so rotating a credential does not disturb a subscription. Cross-tenant isolation is asserted by test and exercised under concurrency by a harness that runs the metering path across multiple processes.

Yes, by running the container in the customer's own environment. That is the strongest isolation available and it is the recommended option for a customer whose risk assessment does not accept logical separation.

TLS is terminated by the hosting platform in front of the application, so the hosted service is HTTPS only. The application does not itself terminate TLS. In a customer-hosted deployment, transport security is the customer's to configure, which is stated here rather than assumed.

Database contents rely on the hosting platform's encryption at rest. Signing keys are separately encrypted when DTL_KEYSTORE_PASSPHRASE is set, and the status command reports honestly when it is not, rather than claiming a protection that is absent.

Yes. PENDING, ACTIVE, RETIRED, REVOKED and DESTROYED, with metadata for algorithm, scope and every transition timestamp. Key identifiers are derived from the public key and are never reused.

Yes, from a command line, offline, in under five minutes. A dry run reports the impact without changing state. Executed evidence from a real rotation, including the audit events and verification of packs from both sides of the boundary, is regenerated on demand.

Yes. Each chain entry records the key identifier that signed it, and verification resolves that identifier rather than reaching for the current key. A test asserts that a pack signed before a rotation verifies after it, and a second test asserts that verifying the whole chain against only the current key fails, so the property cannot silently regress.

Verification fails closed and the attempt is written to the audit trail. There is no fallback to another key, because falling back would convert a key compromise into a working forgery.

No interface returns it, no log line contains it, and it is not embedded in evidence packs. A test extracts the real private bytes and asserts their absence from the evidence envelope, operator status, the key listing, the exported public material, the audit trail, the public transparency slice and the keystore index.

No. Keys are software keys held by the service. There is no HSM and no claim of one. A provider interface exists so that AWS KMS, Azure Key Vault, Google Cloud KMS or a PKCS#11 HSM can be added without changing what an evidence pack means, because packs reference a key identifier rather than key material. No such provider is configured today, and the status command reports hardware_backed as false.

No. EcoKure has one director, who requests, approves and performs every custody operation. This is a genuine gap and is recorded as one. The compensating control is that every operation writes an immutable audit event naming the actor, and the trail can be given to a customer for independent review.

Yes, with the ordering that matters: rotate first to restore a good signing identity, then contain, establish the exposure window from the recorded key identifiers, and only then revoke. Revocation requires a reason, which is published with the key status.

No. Rotation takes a cross-process lock and the one-active-key invariant is asserted on every write. Tests drive eight concurrent threads and four concurrent processes at the same keystore and assert a single active key survives.

Yes. The keystore index is written once, at the end, so a failure part way through leaves the incumbent active and records no partial key. A test injects a failure mid-rotation and asserts both, then asserts that a retry succeeds.

A bearer API key presented in a header, bound to a tenant and an entitlement, scoped to the gates the customer bought. Keys are rotatable without disturbing the subscription, and rotation disables the previous credential immediately.

Not for the API, which is machine to machine and uses keys. SAML or OIDC for the administrative interface is not built.

Key issuance requires a separate administrative secret supplied in a header, and is refused outright when that secret is not configured. Key custody operations are deliberately not exposed over HTTP at all, so they remain possible on a host that has been isolated during an incident. Administrative access is held by one person, which is a size problem rather than a design one, and is recorded as a gap under KEY-07.

No formal review cycle exists. With one administrator there is nothing to review today, but this will not remain true and it is not presented as a control.

Every pull request and every push to the main branch runs a fast verification suite, a dependency vulnerability audit with pip-audit, a Semgrep scan, and CodeQL analysis, followed by a container build. A failure blocks the merge.

Automated gates run on every change and cannot be skipped. Human peer review by a second person does not happen, because there is no second person. An external engineer conducted an architecture and code audit of the DTL system; that was a point-in-time review, not a penetration test and not a continuing assurance engagement, and it is described that way in ASR-01.

pip-audit runs against the pinned requirements on every build and fails it on a known vulnerability. An audit on 19 August 2026 reported fourteen advisories across five packages, four against the cryptography library the signing work depends on. Thirteen are now remediated: cryptography, starlette and click were upgraded, along with two packages whose own ceilings had been blocking those upgrades, and python-jose was removed because the code imports PyJWT and never used it, which also removed the unfixable ecdsa advisory it dragged in. One advisory remains and is accepted rather than suppressed: diskcache 5.6.3, unsafe pickle deserialisation, with no published fix. It arrives transitively through llama-cpp-python for its internal prompt cache, is not reachable from any gate or the signing path, and the advisory requires an attacker to already hold write access to the cache directory, at which point they have code execution by other means. Both audit runs are attached so a reviewer can see the before and after rather than our summary of them.

A published security policy with reporting guidance.

A CycloneDX 1.6 document covering 353 components is generated from the built environment, not from the requirements file, because the question a supply-chain reviewer is asking is what is actually present rather than what was asked for. CI regenerates it on every build and publishes it as a build artefact. It covers the Python environment only, and does not describe the base container image, system packages or model weights.

Secrets are supplied through environment variables from the hosting platform's secret store and are not committed. The keystore passphrase is held separately from any keystore backup. There is no dedicated secret manager such as Vault, and secret rotation outside the signing key is manual.

Semgrep and CodeQL run on every change and cover common secret patterns. A dedicated secret scanner with a full history sweep is not configured.

Every verdict is appended to a hash chain whose head is signed, so altering any historical entry changes every subsequent head and is detectable by a single audit walk. This is the Certificate Transparency model applied to verification verdicts. Key custody operations write their own audit events.

Yes. An audit slice endpoint returns the entries and the public keys involved, including across a rotation boundary, and the verification function is pure and shipped so it can be run offline against material we never see.

Application logs and platform health checks exist. There is no security information and event management system, no alerting on anomalous authentication, and no on-call rotation.

A detailed procedure exists for the incident specific to this product, the compromise of the signing key, including containment ordering, exposure window determination, customer notification content and post-incident review. A general incident response plan covering other classes of incident is not written.

For a signing key compromise, affected customers are notified with the key identifier, the exposure window, the replacement key and the re-verification path. Australian Notifiable Data Breaches obligations are assessed on any incident. A contractual notification window is negotiated per agreement and is not yet a standing published commitment.

Hosted deployments rely on the platform's managed database backups, which cover the keystore because it is stored there. Local deployments back up the keystore directory with the passphrase set, so private keys are encrypted before reaching the backup medium. Restoration is verified by running the chain verification, which is a stronger check than confirming files exist. Restore drills are not yet performed on a schedule.

Evidence packs stay verifiable. Verification needs the pack and the published public key, and neither requires us to exist or to be reachable. This is a deliberate property rather than a consequence, and it is the honest answer to the concentration risk of buying from a company of this size.

No RTO or RPO is committed. Publishing a number that has never been tested would be worse than saying this.

Submitted content is not retained. Tenant, entitlement and usage records are kept for the life of the relationship and can be deleted on request. Chain entries are deliberately not deletable, because an append-only log that can be edited proves nothing; they contain a hiding commitment rather than content, so there is nothing about the verification to disclose. A formal published retention schedule does not exist yet.

Not by design. Content submitted for verification may contain personal information depending on what the customer sends, which is why it is not persisted and why the chain stores a commitment rather than a hash of it. A privacy policy is published. A formal data processing agreement template is not yet prepared.

For the hosted service, residency follows the hosting platform's region and is confirmed per agreement rather than asserted here. A customer with a hard residency requirement should take the on-premises or private-cloud deployment, where residency is entirely theirs.

For the hosted service: a container hosting platform and its managed database, a DNS and edge provider, and a source control and CI provider. The current list with legal entity names and processing purposes is maintained by the Director and provided under agreement rather than published here, because a stale published list is worse than a current supplied one. Customer-hosted deployments have no EcoKure sub-processors at all.

No penetration test has been performed and no independent security assurance engagement has been completed. An external engineer conducted an architecture and code audit of the DTL system, which is useful but is neither of those things, and it did not cover concurrency or load. Concurrency was subsequently tested by us, which found and fixed real defects, and that is our own testing, not third party validation.

A fast test suite runs on every change. Key custody, attestation, entitlement and onboarding behaviour are covered by dedicated suites, including concurrency across threads and processes, injected-failure recovery, and an offline test that fails if any custody operation attempts a network connection. A separate harness exercises the metering and chain paths across multiple processes.

None. EcoKure holds no SOC 2 report, no ISO 27001 certification, no HIPAA attestation and no FedRAMP authorisation, and is not in an active certification process for any of them. A customer requiring certified vendors should treat this as disqualifying rather than as a roadmap item.

The product produces tamper-evident, independently verifiable records of verification decisions, which is evidence a customer can use in their own regulatory position. That is a different claim from EcoKure being certified, and the two should not be run together.

A support commitment is published with the enterprise package. There is no contractual uptime service level with credits, and no 24 by 7 on-call. For a customer-hosted deployment availability is theirs, and the gates run without contacting us.

No. Consumption past an allowance is recorded and billed, never refused. A control system that stops verifying because a counter was reached is one nobody should deploy, so the behaviour is asserted by test rather than left to configuration.

Protect API keys and rotate them on staff changes; retain issued evidence packs, including the nonce, since without it a pack cannot be tied to its chain entry; decide who may call which gates; and for customer-hosted deployments, own the host, backups, transport security and keystore passphrase custody.

One director, so no segregation of duties and a real key person dependency. No independent penetration test and no certifications. One accepted dependency advisory with no published fix, assessed as unreachable rather than ignored. No SIEM, no committed recovery objectives, and no on-premises reference installation yet. Signing keys are software keys, not hardware backed. The mitigating structural fact is that evidence packs verify without us, so the failure of the vendor does not invalidate the evidence a customer already holds.