Architecture for trust.
Documented so you can check it.

Every architectural decision Mandate makes has a security or sovereignty rationale. We document the rationale publicly so you can evaluate it.

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

    Tenant isolation is enforced at the database layer on every tenant-owned table; the application can’t bypass it. No application code path can reach another tenant’s rows.

  • 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

    Mandate stores and processes your governance data (the control plane, audit chain, and credentials) on Canadian-owned infrastructure under Canadian law. Content you forward still reaches the provider you choose, in that provider’s jurisdiction, under the redact and block rules you set.

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.

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 data-handling posture support Law 25’s accountability and consent principles, and inform the cross-border transfer assessment it requires (s.17) for organizations with Québec data subjects.

PIPEDA Law 25

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

Every credential has a documented storage posture

How every credential Mandate handles is stored, and why.

Gateway keys

One-way hashed. Plaintext never stored.

The key your application sends to Mandate. It’s shown once, at creation; after that Mandate keeps only a one-way hash, held apart from the secret used to compute it. The stored hash on its own 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 and a dedicated secrets vault, all under the same Canadian jurisdiction as the rest of the system. The specifics are evidenced in the security questionnaire (CAIQ / SIG-Lite) shared under NDA.

  • Per-tenant key namespacing

    Every stored artifact is scoped to a single tenant. Tenant identity derives from a signed credential, never from a spoofable client-supplied field.

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. As the employer and controller, you remain responsible for notifying your workforce that AI traffic is inspected; Mandate supports this with configurable employee notifications on warn, redact, and block.

  • 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 400 days. When your subscription ends, records stay exportable as structured JSON for 30 days, then are deleted.

Documents your risk team will ask for

We keep the security-sensitive detail off this public page and share it with your team during evaluation.

  • Attestation status, stated plainly

    Mandate holds no SOC 2 or ISO certification today. The compensating evidence is an audit trail your team can verify independently (see Verify) and a completed security questionnaire, in CAIQ or SIG-Lite format, shared under NDA.

  • Available on request, under NDA

    Our data processing agreement, master services agreement (including liability, indemnification, and service commitments), current subprocessor disclosure, and the completed security questionnaire. Email contact@mandateco.ca and tell us which you need.

  • Availability and incident communication

    Mandate maintains an incident-response process and notifies affected tenant admins of a confirmed security incident within 72 hours, consistent with PIPEDA and Law 25. Availability commitments and the binding notification timeframe are set out in the MSA and DPA and confirmed during evaluation.

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.

Security concerns?
Report them directly.

If you've identified a potential security issue, report it to the security address below. We acknowledge reports within three business days and coordinate disclosure. Good-faith testing against your own tenant or the published sample packs is in scope; denial-of-service, social engineering, and testing against other tenants are not. We don't pursue legal action against good-faith reporters.

General enquiries: contact@mandateco.ca