How Mandate works

• 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.

• 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.

• Least-privilege admin roles

  Separate roles for platform admins, tenant admins, and read-only auditors, enforced at every endpoint. Access follows your identity provider: when SSO deprovisions a person, their Mandate access goes with it.

• 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. No application code path can reach another tenant’s rows: the boundary is enforced in the database, not by a policy an operator could change.

• 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. Each department stays isolated, and the org sees a rollup rather than another department’s raw records.

• 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

  The admin console is built and tested to WCAG 2.1 AA across its routes. Bilingual EN + FR (Quebec) localization on the admin SPA.

• API gateway path

  Change one base URL: requests that went to https://api.openai.com/v1 route 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, scoped to the AI destination hosts you configure, so other HTTPS traffic is passed through untouched. The interception certificate is generated per customer; IT installs it once, and 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.

• Alongside your existing controls

  Mandate governs AI traffic and sits beside your SWG, SASE, and DLP, covering the AI-specific gap they leave open. It complements that stack rather than replacing it.

• Governance for the tools you already use

  Mandate is the enforcement and audit layer around approved AI tools. Your team keeps working in the tools it has; you get policy and a record around them.