Tamper-evident audit trail infrastructure for AI in regulated finance.

The conversation around AI in financial services keeps skipping over the bit that actually decides whether a build can ship. The smart model is table stakes. The harder question, and the one the regulator will actually ask, is what evidence you can produce of every decision the system made.

EU AI Act Article 12 sets a six-month floor on retention for high-risk systems. Layer FCA SS1/23 model risk requirements on top and the practical answer is six to seven years of immutable, tenant-isolated, queryable evidence. That is not a "nice to have" feature you add later. It is the difference between a system that gets into production and one that does not.

The architecture answer to that question, which is what we built, has three components.

Four pieces of the design are what make this defensible in a regulatory review. None of them can be added retrospectively to a system that wasn't built with them in mind.

• S3 Object Lock in COMPLIANCE mode. Records cannot be deleted before their retention date. Not by an admin. Not by AWS. Not by the bucket owner. The retention policy is set at deployment and cannot be relaxed without recreating the bucket entirely. This is the storage tier that survives an "we accidentally deleted the audit log" failure mode.
• Hashing happens in the client process, not in the ledger. HMAC-SHA256 over UTF-8 input, keyed off a per-tenant secret the SDK or MCP reads from the environment. The raw prompt and the user input never leave the local process where the MCP server runs, and the hash that does leave is not reversible without the tenant's key. That distinction matters under ICO and EDPB guidance, where plain unsalted hashing of low-entropy values like a name or an email is treated as pseudonymisation at best, often still personal data. What reaches the ledger is the keyed fingerprint, the structured decision, and the metadata. The regulator can verify integrity at any time, and there is no PII at rest in the audit infrastructure to begin with.
• Per-tenant sequence numbers prove no records have been deleted. Tamper-checking only catches alteration of records that are still there. A row deleted from the queryable database leaves no fingerprint on its own. Every successfully stored decision gets a monotonic sequence number assigned by the processor, and a verify-completeness endpoint returns any gaps. A missing sequence number is a deleted, lost, or never-written record. S3 Object Lock already makes S3-side deletion impossible; this closes the database-side gap, which is the one a careful reviewer asks about. Limitation worth stating: this catches loss after the record reaches the processor, not loss before it (network drops, SDK timeouts past retry budget). Those are covered by the dead-letter queue and SDK retries, which is a separate, narrower guarantee.
• Two-key namespace separation. Write keys cannot read. Read keys cannot write. Tenant scoping is enforced at the API Gateway layer using the key prefix, not just inside the application. A leaked write key cannot be used to exfiltrate data. A leaked read key cannot be used to plant fake records.

The four together are what let a regulated team answer "yes, we can produce the audit trail, yes we can prove it has not been tampered with, and yes we can prove nothing has been deleted from it" without having to argue any of the three.

The infrastructure lives in your AWS account, not ours. Deployment is via CDK into a tenant you own. The keys, the encryption material, the data, the access policies, all of it sits inside your security boundary. Zyvra has zero ongoing access after the support window closes.

You wire it into whatever monitoring you already use: Datadog, Splunk, CloudWatch, the lot. There is no parallel observability stack to maintain. The audit-ledger reports its CloudWatch metrics like any other AWS service, and your existing on-call wakes up to the same alerts they always have.

When a regulator audit needs to pull a year of records, your team runs the query in your account against your data. Nothing leaves your environment to make that happen. The infrastructure produces the evidence; the deploying organisation owns the attestation.

The MCP server ships with a zero-config sandbox mode. Run it with no environment variables and it writes to a shared public tenant on a hosted instance of audit-ledger. Drop this into Claude Desktop, Cursor, LangGraph, or any other MCP client:

You can then call record_decision, verify_decision, verify_completeness, and list_decisions from within the client. Records you write are visible on the public sandbox dashboard. Rate limited to a hundred requests per minute. Do not write real personal data: the sandbox keys are public and the tenant is shared.

For production, set the API URL plus your tenant keys (AUDIT_API_URL, AUDIT_WRITE_KEY, AUDIT_READ_KEY) and the server points at your own deployment. AUDIT_HMAC_KEY is strongly recommended so PII hashing uses your tenant-held secret rather than the plain-SHA fallback.

• audit-ledger: github.com/shahidh68/audit-ledger. The AWS infrastructure, SDKs, and dashboard.
• audit-ledger-mcp: github.com/shahidh68/audit-ledger-mcp. The Model Context Protocol server. npm package.
• langgraph-loan-triage: github.com/shahidh68/langgraph-loan-triage. The working LangGraph workflow with HITL.

The architecture is production-grade. AWS managed services give you multi-AZ HA out of the box, and the compliance posture (Object Lock COMPLIANCE, retention, client-side keyed hashing, per-tenant sequence completeness) is what would survive a regulatory audit. The operating layer (alarms, on-call rotation, runbooks, multi-region disaster recovery) is what a customer adds when they deploy it into their own account, alongside whatever monitoring they already run. That split is deliberate. It is a reference implementation that a regulated team takes and operates, not a SaaS product.

It is also not legal advice. Whether the evidence the audit-ledger produces satisfies any specific regulatory obligation is a question for the deploying team's legal counsel. Zyvra builds the technical surface. The deploying organisation owns the attestation.

Audit Ledger is available as a product at one fixed price of £10,000, three ways: hosted and managed by us (inside your own AWS account, with running costs billed by usage), deployed into your AWS account for your team to own and operate, or handed over as code to deploy on your own systems. Full handover of code, infrastructure-as-code, and runbooks either way.

You can also take the open source as it is and run it yourself. The repos include the CDK stack, the SDKs, and the dashboard. The license is Apache 2.0. We made deliberate choices throughout to make self-deployment realistic for an experienced AWS team. When the work is technically possible to self-host, we say so. The reason to bring us in is speed, the compliance review burden, or the integration with your existing systems, not because the source is hidden.