Trust & compliance
Honest about what we are — and what we are not yet.
Six architectural commitments are enforced by the system today. Formal certifications — SOC 2, PCI DSS — are on the roadmap and are not yet complete. This page distinguishes the two clearly. It always will.
Pre-GA status. Mints is in early access. The architecture properties below are real and verifiable. Third-party audits have not yet been completed. We will tell you when they are.
Event stream · illustrative
Illustrative event sequence. Each balance is computed by replaying the event log from origin.
Architectural commitments
Six things enforced by design, not policy.
These are structural properties of the Mints platform. They are not configuration options, and no administrator can override them.
Self-custody mandate
Agent private keys are generated and held on the agent's device. They never touch Mints servers. Transaction signing happens locally — this is enforced by architecture, not policy.
Full Agency Principle
Mints cannot freeze an agent's general funds. Budget controls constrain future spend only. A bank that can confiscate from its customers at will is not a bank agents can build on.
Event-sourced immutability
Every state change is an immutable event. Balances are derived, never edited. Any account's history can be replayed to any point in time.
Authorized at the boundary
Every privileged operation authorizes server-side against centrally managed sessions and per-route permissions. There are no trusted clients.
Lineage isolation
Funding and visibility require proof of shared identity lineage. One organization can never fund, view, or control another organization's agents — cross-lineage requests fail closed.
A custody spectrum, not a custody compromise
Autonomous spend runs on self-custody; treasuries run on guarded custody with multi-sig quorums and guardian recovery. You choose per account, and both sides are audited identically.
Today vs roadmap
What is in place now. What is coming.
The left column describes controls you can verify by reading our architecture and running the code. The right column describes certifications that require third-party assessment — work that is planned but not yet done.
The distinction matters because conflating architectural properties with compliance certifications misleads the buyer. We will not do that.
Enforced today
Architecture properties you can verify now
On the roadmap
Certifications we do not yet hold
A compliance page that conflates roadmap with reality is not a trust page. It is a liability.
Event-sourced immutability
Auditability is architectural, not optional.
Every state change in Mints is an immutable event appended to an ordered log. Balances are derived by replaying this log — they are never stored and edited directly. This means any account’s history is independently reconstructable to any point in time.
The stream below is illustrative. The structure — sequential, typed, timestamped, with derived balances — is the real shape of the system.
Illustrative event sequence. Each balance is computed by replaying the event log from origin.
Lineage isolation
One organization cannot touch another's agents.
Funding, visibility, and control require proof of shared identity lineage. This is not an access-control list an administrator configures — it is a cryptographic proof the protocol evaluates on every request.
Cross-lineage requests fail closed. There is no escalation path, no override flag, and no super-admin that bypasses the check.
Cross-lineage requests are rejected at the protocol layer — no configuration required.
Data handling
Encryption, access control, and audit — defaults, not options.
Here is what is in place for early access customers.
TLS 1.3 in transit
All client-to-API traffic uses TLS 1.3. No plaintext paths exist. Client certificates are used where the deployment model supports them.
AES-256-GCM at rest
Account data, transaction records, and any key material held by Mints is encrypted at rest. Key management is centralized, versioned, and access-controlled.
Least-privilege authorization
Every privileged operation authorizes server-side against centrally managed sessions and per-route permissions. No trusted clients. Tokens are scoped to the minimum capability.
Hash-chained audit
Every system event appends to a tamper-evident chain. This is not an editable log — modification invalidates the chain from that point forward.
Responsible disclosure
We operate a responsible disclosure program. Reports are acknowledged within one business day. See the security page for the full process.
TLS 1.3 in transit
All client-to-API traffic uses TLS 1.3. No plaintext paths exist. Client certificates are used where the deployment model supports them.
AES-256-GCM at rest
Account data, transaction records, and any key material held by Mints is encrypted at rest. Key management is centralized, versioned, and access-controlled.
Least-privilege authorization
Every privileged operation authorizes server-side against centrally managed sessions and per-route permissions. No trusted clients. Tokens are scoped to the minimum capability.
Hash-chained audit
Every system event appends to a tamper-evident chain. This is not an editable log — modification invalidates the chain from that point forward.
Responsible disclosure
We operate a responsible disclosure program. Reports are acknowledged within one business day. See the security page for the full process.
Our disclosure posture
How we communicate about trust.
No data brokering
Transaction data, identity lineage, and usage patterns belong to your organization. Mints does not sell, rent, or broker this data to any third party, ever.
No silent capability claims
We distinguish "enforced by architecture" from "intended by policy" in every piece of documentation. If a control can be bypassed by an admin decision, we say so.
Milestone transparency
Each compliance milestone — penetration test, SOC 2 audit, PCI assessment — will be announced publicly when completed. We will not backdate these announcements.
Incident communication
Any confirmed breach or data-loss event affecting customer data will be communicated to affected customers within 72 hours of confirmation, regardless of regulatory requirements.
Legal
Policies and documentation.
Security & architecture
The full technical breakdown of all six commitments — how each is enforced at the protocol and system layer.
Questions about security or compliance?
Talk to us before you need to. We are glad to walk your security team through the architecture during early access evaluation.