Product
How Mandate works
Every AI request passes through Mandate before it reaches a provider: evaluated against your policy, decided, and recorded automatically.
The mediation path
Every request is evaluated and logged
Mandate sits inline between your users and every provider. The audit record is written automatically: no manual logging, no gaps.
The decision happens inline, inside the latency budget of the AI call; classification and audit enrichment run asynchronously, so your users don’t feel a governance tax. High-sensitivity workflows can opt in to synchronous classification per tenant.
Request forwarded to AI provider. Audit record written on the async path. No user-visible change.
Request forwarded. Employee notified of policy trigger. Event flagged in admin dashboard.
Sensitive fields removed before forwarding. Employee sees redaction notice. Sanitized request reaches provider.
Request stopped. Employee receives a policy-compliant explanation. Request never reaches the provider.
Held for a human to approve before it proceeds. The decision and its outcome are written to the audit record.
Core components
What makes up the governance layer
Each component does one job. Together they give your security and compliance team enough evidence to answer for how AI gets used.
-
Connectors
API gateway for application and developer traffic; network forward proxy for browser-based AI tools organization-wide. One policy engine governs both paths. Traffic you route through Mandate is traffic Mandate can govern.
-
Policy engine
97 typed detectors across 46 bundles: checksum-validated identifiers (credit card, IBAN, SIN, OHIP), cloud secrets for 22+ providers, jailbreak phrases, custom regex. Outcomes: allow, warn, redact, block, escalate. Rules are authored visually in the Workbench; every policy version is immutable after activation.
-
Audit & usage records
One audit event and one usage event per mediated request, joined by correlation id: who, what tool, which rule, what action, when. SHA-256 per-row chain, Ed25519-signed checkpoints, independently verifiable export. Prompt body retention is opt-in per tenant.
-
Compliance evidence
A decision register lists every policy decision and configuration change, each row attributed to its actor, admin or agent. When an auditor asks, export a signed evidence pack that re-verifies offline. Verify a sample yourself.
-
Admin experience
Author and test policies in the Workbench; run the day to day in Operations: dashboard, filterable audit trail, cryptographic proof, usage, signed SIEM delivery.
Agent governance
Agents, governed like your people.
An agent is a named principal: its tool calls run through the same policy engine and land in the same audit chain as your people’s requests.
-
Named agent identity
Each agent is resolved from a verified credential and gets its own identity. Revoke an agent and its next request is refused. Every audit row says which agent acted.
-
Tool-call rules
Policy reads the tool being called and the arguments it carries. Allowlist and denylist per tool, with the same five decision verbs, including escalate to a human.
-
One audit chain for people and agents
An agent action is written to the same SHA-256 hash chain as a human request, attributed to the agent that made the call. There's no separate, weaker log for machine traffic.
-
MCP, natively
Agents connect over MCP (Model Context Protocol) through an OAuth 2.1 ingress. You register the MCP servers a tenant’s agents may reach; every tool call on that route is evaluated and recorded like any other request.
-
Delegation on the record
When an agent acts under a person’s authority, the token exchange that granted it is validated and recorded at the boundary. Every audit row shows who authorized the agent; identities stay with your identity provider.
-
The result leg, governed too
Tool results and responses are evaluated on the way back in: invisible characters stripped, a result held until the decision lands, sensitive spans redacted before the agent reads them.
Result-side control bounds the blast radius of a compromised agent. It does not prevent prompt injection; that comes from how a model reads instructions and data on a single path, and Mandate is one layer in a defence-in-depth design, not a fix for the model.
Any model
One policy and one audit trail, whatever model your team uses.
OpenAI, Anthropic, Google Gemini, Cohere, and Mistral today: point your app at the gateway and it forwards with your own key. A new provider is configuration, not integration work.
Enterprise controls
The controls a security review will ask for.
These are in place from the first tenant.
-
SSO via Azure AD and Okta
OIDC with PKCE, JWKS, and claim-to-tenant mapping. Local password plus TOTP available for admin-only break-glass paths.
-
BYOK provider keys
Provider keys are envelope-encrypted at rest; plaintext exists only in request-scoped memory. Never written to logs, caches, databases, or files. Your provider relationship stays yours.
-
Per-tenant rate limits and concurrency caps
Per-tenant caps on request rate and concurrent streams. At the ceiling the gateway returns 429 and surfaces a saturation metric, so operators see pressure before users do.
-
Response-side classification with optional strict mode
ML classification runs asynchronously by default. Strict mode runs it synchronously before the response reaches the user. Per-tenant toggle.
-
Tenant isolation at every layer
PostgreSQL Row-Level Security on every tenant-owned table; per-tenant caches; namespaced job queues. Cross-tenant access is structurally impossible, not policy-impossible.
-
Departments as isolated tenants
Each department runs as its own tenant with its own policies and audit chain; the organization gets a rollup view across all of them. Isolation first, aggregation second.
-
Webhook delivery to your SIEM
Every audit event exports as a signed JSON webhook to Microsoft Sentinel, Splunk, or any endpoint that accepts a signed payload.
-
WCAG 2.1 AA
Every admin route meets WCAG 2.1 AA. Bilingual EN + FR (Quebec) localization on the admin SPA.
Connector configuration
What IT actually configures
Each connector path is one configuration change, deployed in an afternoon by one person. Nothing is installed on employee machines.
-
API gateway path
Change one base URL: requests that went to
https://api.openai.com/v1route to your Mandate gateway instead, and Mandate forwards them with your BYOK key. No certificate or network changes. -
Network forward proxy path
Configure an explicit HTTPS proxy via PAC file, system setting, or your network policy tool. TLS inspection is required: IT installs Mandate's CA certificate once; employee browsers and applications need no changes.
-
Coverage scope
The gateway covers application and developer traffic; the proxy covers browser-based AI use. Start with one, add the other. Coverage reflects what you route through Mandate.
-
Fail behaviour
Fail-closed by default: if the policy engine is unreachable, requests are blocked, not forwarded ungoverned. Fail-open is available; either way the choice is documented in writing at kickoff.
-
Confirming a setup request
We will never ask you to change a base URL or install a certificate over email or a phone call alone. Confirm any such request in your Mandate admin console first.
Scope clarity
What Mandate is not
We're specific about what Mandate does so you can make an honest evaluation. Coverage is tied to what you route through Mandate's connectors.
-
Not a Secure Web Gateway
Mandate handles AI traffic governance. It is not a replacement for your existing SWG, SASE, or DLP tools. It sits alongside them, covering the AI-specific gap they don't address.
-
Not a model or AI product
Mandate is the governance and enforcement layer around how approved AI tools are used, not a "Canadian ChatGPT" or an AI model provider. Your team keeps using the tools they already use.