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, not because we're pursuing a badge.

Core principles

Four commitments we make to every tenant

These are architectural properties, not policy statements. Each one is structurally enforced. They don't depend on operators doing the right thing.

  • Bring Your Own Key (BYOK)

    Your OpenAI, Anthropic, and other AI provider credentials are stored envelope-encrypted and exist as plaintext only in the request-scoped memory of the single request that uses them. They're never written to logs, caches, databases, or files. Mandate forwards your requests using your key; the plaintext is gone when the request ends. Most AI gateway and governance products require you to hand over your provider credentials in a form they can read at rest. Mandate doesn't. You retain cryptographic control of your provider relationship.

  • Tenant isolation

    Row-Level Security (RLS) is enforced at the database layer on every tenant-owned table. The application role can't bypass it. Cross-tenant data access is structurally impossible. That's enforced at the database layer; it can't be undone by an application-level mistake.

  • Tamper-evident audit

    Audit events are linked by a per-row hash chain. Periodic signed checkpoints make retrospective log manipulation detectable. The trail you produce for an auditor is verifiably unaltered: not just a database export, but a cryptographically attested record.

  • Data sovereignty

    All customer-related data is stored and processed on infrastructure under the legal jurisdiction your counsel cares about, not "a region" operated by a US entity, but structurally outside the reach of CLOUD Act and FISA compulsion. The legal regime is different. That difference is the point.

Data residency reality

Canadian region vs. Canadian law

The difference matters structurally. Mandate is built for the distinction your counsel and privacy officer care about.

US cloud, Canadian region

"ca-central-1": data is in Montreal

The data may be physically located in Canada, but the company that owns and operates the infrastructure is a US entity. The US CLOUD Act and FISA compel US companies to produce data on demand regardless of where the data is physically stored. "Canadian region" is a routing decision, not a legal protection.

Mandate: Canadian envelope

Data in Canada, under Canadian law

Mandate runs on infrastructure owned and operated by Canadian companies. No US entity controls the infrastructure. No US court order reaches Mandate's systems through the CLOUD Act or FISA. This is a structural difference: the legal regime is different from a US cloud operating a Canadian region.

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

Designed with Canadian law in mind

Mandate's architecture is shaped by the Canadian regulatory context its customers operate in. We don't make compliance claims on their behalf. We document the architecture so counsel can make that determination.

  • PIPEDA

    Personal Information Protection and Electronic Documents Act. Mandate's audit trail and data minimization posture (prompt body is opt-in, usage events contain no prompt body) align with accountability and purpose limitation principles. Mandate helps organizations demonstrate due diligence on AI use.

  • Law 25 (Québec)

    Act Respecting the Protection of Personal Information in the Private Sector. Mandate's incident-ready audit trail and data residency posture support organizations subject to Law 25's accountability, consent, and data residency requirements, particularly for organizations with Québec data subjects.

PIPEDA Law 25

The framework descriptions above are architectural characterizations, not legal advice and not compliance certifications.

Credential storage

Every credential has a documented storage posture.

Here is exactly how every type of credential Mandate handles is stored, with the security rationale, not just the conclusion.

Gateway keys

HMAC-SHA256(pepper, secret)

The key your application sends to Mandate. Plaintext leaves the system exactly once: at creation, shown to you. After that, only the HMAC is stored. The pepper is a server-side secret not stored alongside the hash, making rainbow table attacks ineffective. Compromise of the hash database alone doesn't yield usable keys.

BYOK provider keys

Envelope-encrypted. Request-scoped plaintext only.

Your OpenAI, Anthropic, and other AI provider keys are stored envelope-encrypted. Plaintext exists only in request-scoped memory during the single request that uses it. It is never written to logs, caches, databases, or files. When the request ends, the plaintext is gone. This is the architecture others don’t offer.

  • Secret management posture

    Secrets management follows a documented, layered architecture: from isolated environment configuration to HashiCorp Vault OSS to hardware-backed secrets. No US KMS. Each layer is reviewed and documented in the architecture before it is deployed.

  • Per-tenant key namespacing

    All cache keys and async job payloads are tenant-namespaced. No cross-tenant shared entries. Tenant identity derives from a signed credential, never from a client-supplied body or header field that could be spoofed.

Security architecture in depth

The implementation behind the claims.

For organizations evaluating Mandate technically: the specific algorithms, key management patterns, and chain integrity mechanism, so your security team can assess them directly.

  • BYOK envelope encryption: two-layer AES-256-GCM

    Each BYOK provider key is stored using a two-layer envelope. A randomly generated 256-bit data encryption key (DEK) encrypts the provider key plaintext using AES-256-GCM. A 256-bit key-encryption key (KEK) stored in the secrets backend then encrypts the DEK using AES-256-GCM. The database stores the wrapped DEK and the encrypted ciphertext. The KEK is never stored alongside the data it protects.

    At request time: the KEK unwraps the DEK, the DEK decrypts the plaintext, the plaintext is used in-process, and the DEK is zeroed from memory using CryptographicOperations.ZeroMemory before the object is released. The plaintext exists only in process memory for the duration of the request. Compromise of the database yields only ciphertext; a separate compromise of the KEK store is required to decrypt it.

  • Hash chain: SHA-256 per-row linking

    Each audit event stores two SHA-256 fields: a hash of the request body at evaluation time (request_body_hash), and a hash linking to the previous event in the chain (chain_prev_hash). The chain starts from a signed genesis entry. Each event's chain_prev_hash is the SHA-256 of the preceding event's chain-relevant fields (tenant ID, event ID, timestamp, policy decision, and the previous chain_prev_hash). The chain is anchored by periodic signed checkpoints.

    To verify integrity: recompute each event's hash from its fields and compare against the stored chain_prev_hash of the next event. Any modification, deletion, or insertion breaks the chain. Signed checkpoints ensure that a reconstructed chain cannot produce a valid checkpoint signature without access to the signing key, making retrospective manipulation detectable.

  • Gateway key storage: HMAC-SHA256 with server-side pepper

    The gateway key your application sends to Mandate is stored as HMAC-SHA256(pepper, secret). The pepper is a server-side secret, not stored alongside the hash. Only the HMAC is persisted; the plaintext is never stored after the key is first shown. Compromise of the hash database alone doesn't yield usable keys, because the pepper is required to reproduce the HMAC for any candidate secret. The first time the key is shown to you at creation is the only time the plaintext exists in the system.

Data handling and retention

What Mandate observes, stores, and retains.

Precise scope: what Mandate sees in each request, what is written to storage, and what happens to your data at the end of your subscription.

  • API gateway path: what is observed

    Mandate receives the full API request body and the provider response. Both are evaluated in-memory for policy decisions. By default, neither the request body nor the response body is written to storage. What is written to the audit record: request metadata (user, tool, timestamp, correlation ID), the policy decision, the triggered rule identifier, and redacted field identifiers (the pattern type that matched, not the matched content). The SHA-256 hash of the request body is stored for integrity purposes.

  • Forward proxy path: what is observed

    Mandate decrypts HTTPS traffic (TLS inspection) to evaluate request content, then re-encrypts and forwards to the AI provider. Decryption and policy evaluation happen in-process. The same default write policy applies: metadata and policy outcome, not raw content. TLS inspection is required for this path; the CA certificate is installed at the network level by your IT team.

  • Prompt body retention: off by default

    Full prompt body capture is opt-in per tenant with a separately configured retention schedule. It's architecturally off by default for all tenants. Usage events contain no prompt body at any time. That's an architectural constraint, not a configuration toggle. Mandate doesn't use the content of AI requests for any purpose other than policy enforcement, redaction, blocking, and audit recording for your tenant. No cross-tenant aggregation. No model training. Ever.

  • Retention schedule and off-boarding

    Audit events and usage events are retained for the period your organization configures, defaulting to 12 months. When your subscription ends, your audit records are available for export in structured JSON format for 30 days. After that window, records are deleted. Mandate doesn't retain your data beyond the off-boarding period and doesn't use your audit records for any purpose other than serving your own dashboard and export requests.

Auditor's guide

How to verify the audit trail yourself

The hash chain is designed for independent verification. You don't need Mandate tooling to check whether a log has been altered. Here are the concrete steps.

  1. Export the audit log

    From the admin dashboard, export audit events for any date range as structured JSON. Each event contains: event_id, tenant_id, timestamp, user, tool, policy_decision, triggered_rule, request_body_hash, and chain_prev_hash.

  2. Walk the chain

    For each event in sequence: compute SHA-256 over its chain-relevant fields (tenant_id + event_id + timestamp + policy_decision + chain_prev_hash). Compare your result to the chain_prev_hash stored in the next event. A match means the event is unmodified. A mismatch means it was altered, deleted, or something was inserted before it.

  3. Check the signed checkpoints

    At regular intervals Mandate produces a signed checkpoint over the chain state at that point. Verify the checkpoint signature against Mandate's published public key. A valid signature means no retrospective modification occurred before that checkpoint — even if you obtained the export months later.

The verification algorithm and the exact field specification are published in the API reference. The check requires only a SHA-256 implementation and access to the exported JSON — nothing proprietary.

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.

Security concerns?
Report them directly.

If you've identified a potential security issue, report it to the security address below. We acknowledge reports promptly, triage responsibly, and coordinate disclosure. We don't pursue legal action against good-faith reporters.

Email security@mandateco.ca

General enquiries: contact@mandateco.ca