sanction

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

## Need one human approval?

Connect Sanction to your agent, then ask it to call `sanction_authorize_tool`
with `require_approval: true` and the exact proposed action. Approve or deny
through the existing approval link or configured Slack channel. Approval gives
that request an expiring, single-use grant; the agent must redeem it before acting.
No policy edit is required, and blocked actions stay blocked.

Individuals can use Sanction free, without a card. The host must ask and honor the
decision; connection alone does not enforce its other tools.
[Choose your host and try one approval](https://getsanction.com/docs/connect).

## 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:

| Governed action | What Sanction enforces |
|---|---|
| **Spend** (`/authorize`) | Auto-approve floor, human-escalation band, per-transaction hard cap, daily and monthly budgets — checked and debited atomically. |
| **Tools** (`/authorize/tool`) | Block/allow/escalate lists for any MCP tool or external action. Escalations reach the approval inbox like spend does. |
| **Credentials** (`/exec` + `/mandate/verify` + `/credentials/inject`) | AES-256-GCM envelope-encrypted vault (KMS-wrapped, rotating keys). Injection requires a scoped 15-minute mandate JWT and clearance ≥ the credential's bar. Counterparties verify the mandate with no API key. Every access audit-logged. |
| **Provisioning** (`/authorize/provision`) | Seats, licenses, infrastructure — resource, line item, quantity, and dollars authorized in one call. |
| **Capability** (`/authorize/capability`) | Skills, plugins, new APIs — acquiring capability is governed like spending money. One ordered rule list (block / allow / escalate, prefix-glob patterns) gates new power before it lands in an agent. |

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](docs/NOTIFICATIONS.md)
- **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.
- **Observe before enforcing a wallet's policy.** Observe mode records what the
  engine *would* have done while relaxing that wallet's own policy and caps.
  Ancestor subtree caps remain enforced and count observed spend; freeze and
  authentication checks still apply. Review would-be denials and their cost,
  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](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](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:

| You want to… | Use | First step |
|---|---|---|
| Govern any MCP host (Claude Desktop, Cursor, …) | MCP wallet | Paste `https://getsanction.com/mcp` or `npx sanction-mcp` |
| Intercept tools/call and filter tools/list on an MCP server | MCP broker | Register the upstream, point the host at `/mcp/broker/<name>` |
| Meter model spend with zero code changes | LLM gateway | Point the SDK base URL at `/api/gateway/<provider>` |
| Govern agents in a TypeScript app | SDK | `npm install sanction-sdk` |
| Call the engine from anything else | REST API | `POST /v1/authorize` with an `x-api-key` |
| Plug into an AuthZEN enforcement point | PDP | Point it at `/api/access/v1/evaluation` |
| Orchestrate on AWS Bedrock | Action Group | [docs/BEDROCK.md](docs/BEDROCK.md) |

The full menu:

- **MC