Zero-trust for financial data: BYOK and encryption

Financial data is not like other data. A leaked marketing email list is an embarrassment; a leaked general ledger is a map of every supplier, salary, margin and bank relationship a company has. It exposes who you pay, how much you earn, where your cash sits and when it moves. For a finance function operated by AI agents, that data also has to be readable by software in order to be useful — which raises the obvious question a CFO or security reviewer asks first: who, exactly, can see it.

FINMOZG answers that question with architecture rather than promises. The platform is built around a zero-trust model, per-tenant encryption, bring-your-own-key, confidential computing and an immutable audit log. This article walks through each layer and is explicit about what is delivered and what is a design goal.

Zero-trust: never trust, always verify

Older systems granted trust by location. If a request came from inside the corporate network or from a service behind the firewall, it was treated as safe. That assumption fails the moment any single component is compromised, because everything inside the perimeter becomes reachable.

Zero-trust removes implicit trust entirely. No request is trusted because of where it originates. Every access — from a user, an agent or an internal service — is authenticated, authorised against a specific scope, and verified against policy on each call. There is no privileged inside. This matters for an autonomous finance department because agents act continuously and across services; each of those actions is checked, not waved through on the basis of network position.

Per-tenant encryption: an isolated boundary per company

Multi-tenant platforms often share one encryption key across all customers and rely on application code to keep data apart. That is a single point of failure: one logic bug, and tenant boundaries blur.

FINMOZG is built so each tenant — each company — sits inside its own encryption boundary, with its own keys. There are no shared keys across tenants. Data encrypted for one company cannot be decrypted with another company's key material, so isolation is enforced by cryptography rather than by application logic alone. The practical effect is that a problem in one tenant cannot cascade into another.

Bring-your-own-key: the customer holds the keys

Encryption only answers "who can read this" if you also control who holds the key. Bring-your-own-key (BYOK) moves that control to the customer.

• Keys live in your KMS. The master key originates from and stays inside your own key management service. The platform performs cryptographic operations against it rather than holding it.
• You rotate and revoke. Key rotation and revocation are your decision. Revoking a key is a hard kill switch: the data becomes unreadable, including to the operator.
• The operator cannot read in the clear. Because the operator never possesses your master key, it is designed to be unable to decrypt your financial data on its own.

BYOK turns a trust statement into a control you can demonstrate. A security reviewer does not have to take "we won't look" on faith; they can verify that the key never leaves their jurisdiction and that revocation works.

Confidential computing: agents work on data the operator cannot see

Encryption at rest and in transit is standard. The harder problem is data in use: to classify a transaction or prepare a filing, an agent has to work with plaintext at some point. On ordinary infrastructure, that plaintext is exposed to the host while it is being processed.

FINMOZG is designed so AI agents execute inside confidential-computing environments — hardware-protected enclaves where data is decrypted and processed in memory that the surrounding operating system, hypervisor and operator cannot read. Remote attestation lets the workload prove it is running the expected, unmodified code inside a genuine enclave before any keys are released to it. The goal is a chain where plaintext financial data is never exposed to operator infrastructure, even during computation.

The data-flow chain

Put together, these layers form a single path that data travels, with control held by the customer at the front and accountability captured at the end:

• User device. Data and instructions originate from an authenticated user or system, verified per request under zero-trust.
• Client key / KMS. Encryption and decryption are gated by keys the customer controls in their own KMS — the platform requests operations, it does not own the master key.
• Encrypted data vault. Each tenant's data sits at rest inside its own encryption boundary, with no shared keys across companies.
• Confidential compute runtime. Agents process plaintext only inside attested, hardware-protected enclaves, designed to keep it out of reach of the operator.
• Immutable audit log. Every action that touches the data is recorded in an append-only, hash-chained log.

The immutable audit log

Autonomy is only acceptable in finance if every action is accountable after the fact. FINMOZG records each agent and human action to an append-only, hash-chained log. Each entry is cryptographically linked to the one before it, so removing or editing a past record breaks the chain and becomes detectable rather than silent.

Every entry is designed to answer the questions an auditor actually asks:

• Who performed the action — a named user or a specific agent.
• When it happened, to a precise timestamp.
• What changed — the exact posting, filing or payment.
• Which agent was involved and under what autonomy setting.
• What evidence supported it — the source document and reasoning.
• Who approved it, for any action that required human sign-off.

Least-privilege access governance

Zero-trust on the network is matched by least privilege on access. Each person sees and does only what their role requires, and nothing more. The model maps to the real people around a company's books:

• Owner — full administrative control of the entity and its settings.
• Accountant — day-to-day bookkeeping, classification and reconciliation.
• CFO — analytics, approvals and treasury decisions.
• Auditor — scoped, read-oriented access to records and the audit trail.
• External consultant — time-bounded, narrowly scoped access for a defined engagement.
• Read-only investor — visibility into reports without the ability to change anything.

What this means for a security review or a bank

Security and partnership reviews come down to a short list of questions, and this architecture is built to give concrete answers to each:

• Can the vendor read our data? BYOK and confidential computing are designed so the answer is no in the clear — and key revocation is a control you hold, not a request you file.
• How are tenants isolated? By per-tenant encryption with no shared keys, so isolation does not depend on application code being bug-free.
• Can someone rewrite history? The hash-chained, append-only log makes tampering detectable.
• Who can touch what? Role-based least privilege limits every actor, internal or external, to a defined scope.

To be precise about claims: this article describes the architecture and design principles of the platform. Where a capability is a design goal rather than a finished, independently verified control, it is stated that way. FINMOZG does not represent itself as holding any specific external certification, and any audit or attestation status is reported separately on the security page rather than asserted here.

Zero-trust is not a feature you switch on; it is the assumption the whole system is built on — that no component, network or operator should be trusted by default with a company's most sensitive numbers. For how the agents themselves operate under these controls, see the agents, how AI bookkeeping works, and what an autonomous finance department is. If you are running a vendor review, contact us for the detail.