Architecture

How Sanction works

Sanction is an authorization plane, not a platform. Identity stays upstream, every agent action passes through one atomic decision, and every decision leaves evidence you can replay. One diagram:

Upstream

Identity — yours, not ours

Entra, SPIFFE, agent cards, plain API keys. Sanction consumes canonical identity and mints governed runtime identity (scoped keys, short-lived execution tokens) — never an identity of record.

The decision

One atomic evaluation

Spend, tool call, credential access, provisioning, new capability — every action type rides the same pure rules engine. Policy, budgets, approvals, grants, ledger, and audit resolve together; there is no gap between “allowed” and “paid for.”

  • Policy rulescategories, per-transaction caps, tool and resource lists
  • Budget statedaily, monthly, and cascading subtree caps — read under lock
  • Capability rulesnew skills, plugins, and APIs governed like money
  • Escalation bandamounts and actions that require a human
  • Evidencethe revision in force and the exact context evaluated, stored

Allow

The action proceeds and the budget debits — in the same atomic evaluation, so sibling agents can't race past a shared cap.

Escalate

A human approves wherever they are (dashboard, email, Slack). Approval mints a one-use, expiring grant the agent redeems on retry. Timeouts guarantee a terminal outcome.

Deny

Never a dead end: a machine code, the limit that fired with live values, when the answer changes, and — on budget denials — a signed offer to appeal to a human.

Downstream

Execution — wherever the agent runs

Sanction belongs to no platform. The same decision answers over REST, the TypeScript SDK, MCP, an AWS Bedrock action group, the LLM gateway, or the OpenID AuthZEN wire — so governance travels with the agent instead of living inside one vendor’s walls.

Why this shape

The full argument — six claims, from “identity isn’t authorization” to “governance should travel with the agent” — lives at Why Sanction.

Deterministic

Same request + same policy revision + same state ⇒ same decision. The rules are pure functions; the enforcement shell does the IO. That’s what makes replay possible at all.

Evidenced

Every policy edit becomes an immutable revision; every decision stores the revision in force and the exact context it evaluated. Ask “why was this denied?” and get a replay that proves the answer.

Explorable

The same purity runs time in both directions: dry-run a request before it happens, or replay last week under a candidate policy and see exactly which decisions would flip — before you change anything.

Now make it concrete

Quickstart →First governed call in five minutes.Integration guides →Vercel AI SDK, LangChain, CrewAI, MCP.API reference →OpenAPI 3.0, Bedrock-compatible.