Trust & security
Architecture for trust,
not marketing for compliance.
Every architectural decision Mandate makes has a security or sovereignty rationale. We document the rationale publicly so you can evaluate it.
Core principles
Commitments we make to every tenant
Each one is a structural property of the system, enforced whether or not an operator does the right thing.
-
Bring Your Own Key (BYOK)
Provider credentials are envelope-encrypted, with plaintext only in request-scoped memory. Mandate never stores your key in a form it can read at rest.
-
Tenant isolation
Row-Level Security is enforced at the database layer on every tenant-owned table; the application role can’t bypass it. Cross-tenant access is structurally impossible.
-
Tamper-evident audit
A per-row hash chain with periodic signed checkpoints makes retrospective manipulation detectable. The trail an auditor gets is verifiably unaltered, and they can check it independently.
-
Data sovereignty
All customer data is stored and processed on Canadian-owned infrastructure under Canadian law. Your counsel can evaluate which legal regimes can compel access before you sign.
Data residency reality
Canadian region vs. Canadian law
That difference is structural, and it's the one your counsel and privacy officer will ask about.
Region label
e.g. “ca-central-1”: data is in Montreal
A region label says where data sits, not which legal regime applies to the company controlling it. The US CLOUD Act reaches data held by US-headquartered entities regardless of location; equivalent provisions exist elsewhere. Vendor jurisdiction is a separate property your counsel evaluates.
Mandate: vendor jurisdiction is named
Data in Canada, under Canadian law
Mandate runs on infrastructure owned and operated by Canadian companies. The jurisdiction is named, and your counsel can verify it.
Note: This is a description of the architectural posture, not legal advice. Counsel should evaluate applicability to your specific privacy obligations and regulatory context.
Regulatory context
Shaped by Canadian regulatory context
We don’t make compliance claims. We document the architecture so your counsel can make that determination.
-
PIPEDA
Personal Information Protection and Electronic Documents Act. The audit trail and data-minimization posture (prompt body opt-in, no prompt body in usage events) align with accountability and purpose-limitation principles.
-
Law 25 (Québec)
Act Respecting the Protection of Personal Information in the Private Sector. The audit trail and residency posture support Law 25’s accountability, consent, and residency requirements for organizations with Québec data subjects.
The framework descriptions above are architectural characterizations, not legal advice and not compliance certifications.
Credential storage
Every credential has a documented storage posture
How every credential Mandate handles is stored, and why.
Gateway keys
HMAC-SHA256(pepper, secret)
The key your application sends to Mandate. Plaintext is shown once, at creation; after that only the HMAC is stored, and the pepper lives apart from the hash. The hash database alone yields no usable keys.
BYOK provider keys
Envelope-encrypted. Request-scoped plaintext only.
Stored envelope-encrypted. Plaintext exists only in request-scoped memory during the single request that uses it, never in logs, caches, databases, or files.
-
Secret management posture
A documented, layered posture: isolated environment configuration, a dedicated secrets vault, and hardware-backed keys, all under the same Canadian jurisdiction as the rest of the system.
-
Per-tenant key namespacing
Caches and job payloads are tenant-namespaced. Tenant identity derives from a signed credential, never from a spoofable client-supplied field.
Security architecture in depth
The implementation behind the claims
For the security team evaluating Mandate technically: the algorithms, key management, and chain mechanism.
-
BYOK envelope encryption: two-layer AES-256-GCM
Two-layer envelope: a random 256-bit DEK encrypts the provider key with AES-256-GCM; a KEK in the secrets backend encrypts the DEK. The database holds only the wrapped DEK and ciphertext; the KEK is never stored alongside the data it protects.
At request time the KEK unwraps the DEK, the DEK decrypts the plaintext in-process, and the DEK is zeroed from memory (
CryptographicOperations.ZeroMemory). A database compromise yields ciphertext only. -
Hash chain: SHA-256 per-row linking
Each audit event is SHA-256 linked to the one before it, from a signed genesis entry onward; humans and agents share one chain, anchored by Ed25519-signed checkpoints with Merkle roots. A reconstructed chain can’t produce a valid checkpoint signature, so manipulation is detectable even from an export obtained long after the fact.
The exact field specification an auditor needs to recompute and confirm the chain, including the field order and binary framing, is shared with your security team under NDA during evaluation, not published here.
-
Gateway key storage: HMAC-SHA256 with server-side pepper
Stored as
HMAC-SHA256(pepper, secret); the pepper is a server-side secret held apart from the hash. Plaintext is never stored after the key is first shown. The hash database alone can’t reproduce usable keys.
Data handling and retention
What Mandate observes, stores, and retains
What Mandate sees, what it writes to storage, and what happens to your data when you leave.
-
API gateway path: what is observed
The full request and response are evaluated in-memory; by default neither body is written to storage. The audit record gets metadata (user, tool, timestamp, correlation id), the decision, the triggered rule, the pattern type that matched (not the matched content), and the request body’s SHA-256.
-
Forward proxy path: what is observed
Mandate decrypts HTTPS traffic (TLS inspection) in-process to evaluate it, then re-encrypts and forwards. The same default applies: metadata and policy outcome are written, not raw content. Your IT team installs the CA certificate at the network level.
-
Prompt body retention: off by default
Prompt body capture is opt-in per tenant, with its own retention schedule; usage events never contain a prompt body. Request content is used for policy enforcement and audit recording for your tenant only: never aggregated across tenants, never used to train models.
-
Data subject requests
Subject-scoped audit records export as a signed access pack; deletion leaves a verifiable trace in the chain. The legal determination stays with your privacy program.
-
Retention schedule and off-boarding
Audit and usage events are retained for the period you configure, defaulting to 12 months. When your subscription ends, records stay exportable as structured JSON for 30 days, then are deleted.
Auditor's guide
Verify the audit trail without trusting us
Your auditor can confirm an exported log was not altered, using only the export and standard SHA-256 and Ed25519 implementations. No Mandate software in the loop.
-
Independently checkable
Altering, deleting, or inserting any record breaks the chain, and Ed25519-signed checkpoints anchor the trail. The check needs only the public key, which travels with the export.
-
Two levels of specification
The evidence-pack and checkpoint format is public, with sample packs and the verifier published on the verify page. The deeper per-event chain specification is shared with your auditor under NDA during evaluation.
If a client's legal team or external auditor asks whether your AI governance records can be relied on as a contemporaneous, unmodified log: this is the architecture behind your answer.