Five stories for people and engineers. Five for autonomous agents.
THE COMMON THREAD
One action. One decision.
Start with a one-off approval. Add shared policies, budgets, and scoped access as the work grows.
01
Propose
An exact action, its arguments, and a reason.
02
Decide
Policy allows, escalates for review, or denies.
03
Review
An authorized person decides an escalated request.
04
Redeem
After human approval, the agent redeems one expiring grant for the same action.
Changed arguments require a new decision. Hard limits still deny. Approval does not execute the action; the caller or governed integration takes the next step.
KNOW THE BOUNDARY
The decision is shared. Control depends on the path.
COOPERATIVE
The agent honors the answer.
Over the approval connector, an agent asks Sanction, waits when needed, and proceeds only when the response says to proceed. Sanction cannot stop a separate action that bypasses that decision.
Approvals connector: /mcp/approvals. An approval gives authority for the matching request, not proof of execution.
ENFORCED PATH
The execution path checks the answer.
The MCP broker checks governed tool calls before forwarding. The model gateway applies its budget checks before supported provider calls. An SDK integration enforces a decision only when the calling code gates execution on it.
The full wallet MCP profile adds tools; connecting it alone does not put downstream actions behind an enforcement boundary.
THE STORIES
Where the pause matters.
Illustrative scenarios, with the review scope and integration boundary made explicit.
An engineer asks a coding agent to run a migration on the billing database. The agent doesn't just run it. It sends Sanction the exact command, the target, and why, and waits. The wallet owner or an admin reads that exact proposal in the dashboard and approves it. The agent gets a one-use grant for that command and nothing else.
1Agentmigrate billing · --target prod
2Escalatedrequire_approval · reason given
3Owner reviewsexact command · approves once
4Grant1 use · expires · args bound
A retry with a different --target is refused and needs a new decision.
What is reviewed
The tool, the server, and the full arguments: the actual command, not a summary of it.
Technical detail & boundaries
Cooperative path
sanction_authorize_tool with require_approval: true, then check after review and redeem with the grant_id. An unanswered explicit approval request times out to denial.
Enforced path
Put the deploy or infrastructure MCP server behind Sanction's broker. The call is forwarded only with an allowed decision.
Boundary
Sanction governs calls routed through it. Approval authorizes the proposed operation; it does not establish that a deployment is safe or execute the deployment.
Someone needs a paid API plan or extra compute that crosses their normal review threshold but remains within the hard budget. They don't edit the standing budget and they don't need an exception that lasts all quarter. They ask for that one purchase. A person approves that amount for that purpose, and the budget policy stays as it was.
1Request$240 · compute · for this job
2Over thresholdescalate_over_usd
3Approverthis amount · this purpose
4Policy intactstanding budget · unchanged
Illustrative amounts, with timeout-deny configured. Hard limits still deny, even with a person available.
What is reviewed
The amount, what it pays for, and the reason. The standing daily budget isn't changed.
Technical detail & boundaries
Cooperative path
sanction_authorize with the amount. Policy escalates above the review threshold, and the agent waits for the decision.
Enforced path
The LLM gateway meters supported calls and returns 402 on new calls once recorded daily usage reaches the budget. In-flight usage can cross the budget. External purchases need a caller that honors the decision.
Boundary
Ordinary policy escalations can be configured to approve on timeout; that is a policy decision, not human approval. Neither path raises a hard budget limit or makes a payment.
An assistant drafts a customer email, a contract redline, or a public post. Before it sends, it submits the real recipient and the real content. A human approves that exact message to that exact recipient. If the agent edits the content or changes the recipient afterward, that's a new decision.
1Draft readyto: renewal@… · body + attachment
2Escalatedoutbound send
3Admin reviewsexact arguments · in dashboard
4Send oncesame recipient · same content
Full tool arguments are reviewed in the dashboard by the wallet owner or an admin. Optional Slack cards link there.
What is reviewed
Recipient, subject, body, and attachments, exactly as the send tool will receive them.
Technical detail & boundaries
Cooperative path
The send tool's arguments go into sanction_authorize_tool with require_approval: true. The agent sends only after proceed, using the matching grant_id.
Enforced path
Route the email or social MCP server through the broker so the send is forwarded only with an allowed decision.
Boundary
Dashboard approval requires the wallet owner or an admin. With Slack configured, people able to use the approval buttons in that channel can decide; viewing full arguments still requires dashboard admin access.
A contractor's agent needs to work in your repository for two weeks. You don't share your keys. You give it its own agent seat with a tool allow-list, a budget, and an expiry date. Sensitive credentials stay in the vault and are used only on the governed execution path. When the seat expires, the key stops working.
1Contractor seatown key · own identity
2Scoped policytool allow-list · daily budget
3Vaultcredentials stay · server-side
4Expireskey fails closed · after end date
Illustrative flow. Policy and the integration path determine the decision.
What is reviewed
Anything outside the allow-list or above budget escalates or is denied. Expiry is automatic.
Technical detail & boundaries
Cooperative path
Over the approvals profile, the contractor's agent asks Sanction and honors the answer.
Enforced path
Give the contractor the broker URL, not the upstream. Calls are policy-checked, tools/list shows only allowed tools, and the upstream credential is injected server-side.
Boundary
Enforcement covers the governed execution path. Separate access to an upstream service remains outside that boundary.
A team researches in one assistant, builds in another, and decides approval requests in Slack. Each agent connects to the same Sanction wallet under its own identity. Whichever tool asks, decisions land in one shared history, and the team can see what was requested, who decided, and what was redeemed.
1Researchassistant A
2Buildassistant B
3One servicesame policy · same wallet
4One historyevery decision · every host
Each host needs its own configured connection and agent identity.
What is reviewed
Each request on its own merits, attributed to the agent and host that sent it.
Technical detail & boundaries
Cooperative path
Each host connects to the approvals profile. Every agent asks the same service before acting.
Enforced path
Tool traffic routed through the broker is checked before forwarding. An SDK integration enforces the decision only when its calling code gates execution on that decision. Other paths remain cooperative.
Boundary
Connection and enforcement depend on each host’s integration. Sharing a decision history does not make every host an enforced execution path.
An agent does routine paid work inside its allowance without interrupting anyone. With timeout-deny configured, an expense above the review threshold waits for a person or is denied when time runs out. When an action would break a hard limit, it gets a denial, and asking a human doesn't change that.
1Routinewithin allowance
2Large expenseover threshold
3Escalateone review
4Hard limitdeny · no · override
Illustrative flow. Policy and the integration path determine the decision.
What is reviewed
Only the expense that crossed the threshold. Routine spend stays quiet.
Technical detail & boundaries
Cooperative path
sanction_authorize before each spend returns allow, escalate, or deny. sanction_wallet_status shows remaining headroom.
Enforced path
The LLM gateway meters supported calls and returns 402 on new calls once recorded daily usage reaches the budget. In-flight usage can cross the budget; this budget check is separate from the approval-and-grant loop.
Boundary
An escalation timeout does not override hard limits. Gateway checks happen before provider calls; in-flight usage can affect the final cost.
Before it installs a skill, enables a plugin, or calls a new API, the agent asks. The organization's capability policy allows it, escalates it, or blocks it. Gaining a new capability is governed the same way spending money is.
1Wantsskill:install: · web-reader
2Capability rulesblock → allow → · escalate
3Reviewif escalated
4Decisionrecorded
Rules use namespaced IDs with prefix matching, e.g. api:github.com/*
What is reviewed
The namespaced capability the agent wants, e.g. skill:install:… or api:….
Technical detail & boundaries
Cooperative path
sanction_authorize_capability before the install or the first call to the new API.
Enforced path
Enforced where the install or API path goes through Sanction. A host's own plugin installer stays cooperative.
Boundary
Authorization records a decision; it does not install a skill or plugin. A host’s own installer must honor that decision or gate execution itself.
The agent reaches a step that needs human judgment. It submits the exact action, pauses, and checks back. Once someone approves, it redeems the grant for that identical action, one time. If the arguments change, it has to ask again. If redemption fails, it stops and reports instead of asking again on its own.
1Submitexact action
2Waitnext_action: wait
3Redeem onceidentical input · + grant_id
4Changed argsnew decision · required
If redemption fails, the agent stops and reports. It doesn't re-request automatically.
What is reviewed
The paused action, exactly as it will run.
Technical detail & boundaries
Cooperative path
sanction_authorize_tool with require_approval: true → check after review → retry_with_grant → proceed. Without a human decision, the request times out to denial.
Enforced path
The same loop through the broker: the forward happens only with the redeemed grant.
Boundary
A grant authorizes one matching request. An outcome log records what the caller reports; it is not independent proof that the action ran.
An agent needs to call an API that requires a secret. It holds its Sanction key. A governed integration—the MCP broker or LLM gateway—adds the stored upstream credential on the server side. The agent can complete the supported call without receiving the credential as a tool result.
1Agentholds only · its Sanction key
2Authorizescoped operation
3Injectserver-side · from vault
4Upstream APIcredential added · server-side
Broker and gateway inject server-side. sanction_inject_credential hands the value to the agent, so it isn't this story.
What is reviewed
The operation and its scope. Calls to the vaulted provider key are limited to metered endpoints.
Technical detail & boundaries
Cooperative path
Not applicable. This story is about the enforced path by definition.
Enforced path
The broker decrypts and injects the upstream credential server-side. The gateway injects a stored provider key for supported metered calls. Both keep credential handling on the forwarding path.
Boundary
Sanction stores encrypted credentials. Server-side injection avoids returning the credential as a tool result; upstream responses must not echo secrets. The direct credential-injection tool returns a credential value and is a different path.
Collaborate without passing around blanket authority
A research agent hands work to a purchasing or deployment agent. Each one acts under its own identity and its own limits. The handoff passes the work, not permission. The receiving agent asks Sanction for what it intends to do.
1Researchown identity
2Handoffwork, not · permission
3Purchasingown identity · own limits
4Asks againits own decision
A handoff does not transfer an approval. Each agent remains accountable for its own request.
What is reviewed
The receiving agent's proposed action, under the receiving agent's own policy.
Technical detail & boundaries
Cooperative path
Each agent connects with its own identity and asks before acting. An approval granted to one agent can't be redeemed by another.
Enforced path
The receiving agent calls through the broker under its own identity. Sanction checks that agent's policy before forwarding the call. Agents keep separate keys.
Boundary
Approvals are bound to an agent and cannot be transferred to another.
START WITH ONE DECISION
If you’re not sure, Sanction it.
Connect your agent and walk through a safe approval request. Review the proposal, decide, and see the grant redeemed without running a real action.