Sanction

The independent authorization plane for AI agents.

Before an agent spends money, invokes a tool, touches a credential, or provisions a resource, it asks Sanction. Sanction approves, escalates to a human, or denies. Every decision is logged and auditable. Sanction belongs to no platform: one policy engine answers across model providers, payment rails, identities, and agent ecosystems.

Who runs Sanction

• Organizations governing their own AI — the primary case. Teams and departments become wallets in a tree; budgets, tool rules, and approval bands are enforced — not dashboarded — with chargeback-ready reporting underneath. Alerts tell you what happened; a decision happens first.
• Platforms and agencies embedding governance — agents you ship or run for clients carry a wallet wherever they execute: MCP hosts, Bedrock, your own stack via SDK or REST.
• Individuals — free, no card, personal and production use.

What it does

One policy decision engine governs every kind of agent action:

What a decision looks like in practice — one POST /authorize with an amount, three possible outcomes, all of them terminal or resumable:

• Approved → { "status": "approved" }; budget counters debit in the same transaction the decision persists (an advisory lock makes sibling agents queue, not race).
• Escalated → { "status": "escalated", "request_id": "…" }; a human sees it in the approval inbox, and approving mints a one-use grant the agent redeems by retrying with grant_id. Policy decides what a timeout means (approve or deny) — nothing hangs forever.
• Denied → { "status": "denied", "decision_code": "PER_TXN_LIMIT", "remediation": "Amount exceeds the per-transaction limit. Split into smaller charges or ask the owner to raise the limit." }. Codes are stable machine strings (DAILY_BUDGET_EXCEEDED, CATEGORY_BLOCKED, WALLET_FROZEN, …) so agents branch and replan instead of parsing prose. Replays of the same request return the same code.

Around the engine:

• Human approvals → one-use grants. Escalations land in an approval inbox (dashboard PWA, email, Slack). Approving mints a single-use, expiring grant the agent redeems on retry. Policy timeouts guarantee a terminal outcome.
• Seats. An agent is a seat you can hand to whoever holds it: named holders, contractor auto-expiry (the key fails closed past the date), key rotation that keeps history, and batch creation from one template.
• Budgets that cascade. Wallets nest into trees; subtree caps are enforced atomically so sibling agents can't race past a parent's limit. The console's spend view draws the month's runway — cumulative burn against the cap, pace, and the projected exhaust date — from wallet down to seat.
• Notifications that find you. Email by default; signed JSON webhooks for machines; and Slack two ways — a pasted incoming-webhook URL that deep-links to the decision, or Add to Slack, which installs per workspace over OAuth and posts interactive Approve / Deny buttons that run the same resolveApproval path as the dashboard, actor recorded. Each route subscribes to its own events. Guide
• Evidence you can replay. Every policy edit becomes an immutable revision; every decision stores the revision in force and the exact context the engine evaluated. GET /authorize/{id}/evidence re-runs the pure rules over the stored context and proves the outcome reproduces.
• What-if over real history. POST /policy/simulate replays stored decisions under a candidate policy — which calls flip, what spend wouldn't clear — before you change anything.
• The audit plane. GET /audit-events merges every decision, token log, and secret access into one feed (CSV export included); GET /reporting/summary spans any period with day buckets and per-seat rollups; wallet stats project burn pace and exhaustion ETAs; a weekly digest lands in Slack every Monday.
• Tamper-evident exports. GET /audit/export hands you a signed, hash-chained snapshot of your governed decisions: altering, dropping, or reordering any row breaks the chain, and the head is HMAC-signed by Sanction. A regulator or the governed customer runs POST /audit/verify — self-contained, no database — to prove nothing changed after signing, down to the first broken link.
• A console that opens on the roster. The dashboard home is the wallet tree as groups with agents as cards, each carrying a mandate stamp (live / paused / blocked). A wallet holds people, not just keys: team membership with roles (owner / admin / viewer), a switcher across every membership, and a viewer who can read everything and change nothing.
• Adopt without enforcing. Observe mode runs the real engine on a live fleet and records what it would have done — blocking nothing, moving no counters — so you can watch a week of would-be denials and the dollars behind them, then flip each pool to enforce in one confirm-gated click.
• Spend answerable to outcomes. Report outcomes (POST /outcomes) and a wallet over its cost-per-outcome ceiling throttles to human-gated spend. Wallets can be frozen outright, and budget reallocated across the tree.
• LLM gateway. Point your model SDK's base URL at https://getsanction.com/api/gateway/<provider> with x-sanction-key — usage is metered and budget-capped with zero per-call instrumentation.

Every security claim above maps to enforcing code and a regression test in docs/TRACEABILITY.md — 1,100+ tests behind a coverage gate of 90% statements/lines, 94% functions, and 83% branches, including concurrency and Postgres row-level-security suites.

Start from a pack, not a blank policy

Eleven installable policy packs cover the common shapes — Startup defaults, Coding agent seat, MCP tool governance, Compliance baseline, Client-safe launch, and No-egress (Sanction Local) among them. GET /policy/packs lists them; POST /policy/packs/{id}/preview simulates one against your last 30 days of real decisions before anything changes; apply writes it as a policy revision.

Changing policy in production

Policy edits are never a leap of faith:

1. Draft the change (or pick a pack).
2. POST /policy/simulate replays your stored decision history under the candidate — see exactly which calls flip and what spend wouldn't clear.
3. Apply. The edit becomes an immutable revision; every subsequent decision records the revision in force.
4. If a decision is ever questioned, GET /authorize/{id}/evidence re-runs the rules over the stored context and proves the outcome reproduces.

When to use the credential vault

Use Sanction's vault when credentials should flow through the same policy, approval, and audit trail as spend and tools — one clearance model, no separate secrets cluster. Keep your existing Vault or Secrets Manager when you need fleet-scale secret lifecycle management independent of agent governance; Sanction consumes upstream identity and secrets rather than replacing them. Threat model: docs/SECURITY.md.

Distribution

Platform vendors govern agents inside their own walls. Sanction authorizes agents wherever they run. Pick the shortest path to your stack:

The full menu: