Define action classes
Examples: read.context, draft.compose, tool.call.local, email.send.external, repo.push, payment.initiate.
Mission Gate for builders
Wrap the provider call. Keep your agent stack.
Mission intercepts consequential tool calls before execution, binds approval to the exact target and input, resumes once under a narrow grant, and emits a signed receipt.
Reference integrations now cover OpenAI Agents SDK and MCP 2025-11-25, with canonical schemas and OpenTelemetry-compatible trace correlation.
30-minute proof
Attempt, interrupt, approve, execute once, verify.
The proof is one real consequential action plus the failure cases: replay, changed target or input, expiry, revocation, and tenant mismatch.
1. Wrap
wrapTool intercepts before the OpenAI or MCP provider call.2. InterruptThe runtime receives
needs_approval with exact target, payload digest, tenant, scope, and expiry.3. DecideA human approves, revises, rejects, or revokes from Mission Control or another compatible interface.
4. Resume onceThe unchanged action executes once under the grant; mutation or replay fails closed.
5. VerifyAn Ed25519-signed receipt binds the provider result and OpenTelemetry trace context.
Where it fits
The trust unit is the action class.
Do not start with the tool name. Start with the consequence. The same tool can be safe for one action class and unsafe for another.
MCP appsExpose allowed tools only when the action class has evidence; block invocation when approval is missing.
Coding agentsLet read and patch graduate separately from shell commands, commits, pushes, and pull requests.
Browser agentsNavigate and extract can be low risk; form submit, purchase, send, and account mutation stay gated.
Evals / observabilityUse receipts from supervised work as permission evidence, not only retrospective quality data.
Enterprise workflowsKeep every approval, refusal, and executed external action attributable and reviewable.
Agent discovery
Make the permission layer discoverable.
Agents should not need to read marketing pages to find the trust boundary. Publish a small manifest, return structured decisions, and make every denial point to a safe next action.
/.well-known/trust-graduationDeclare supported protocol version, schemas, action classes, decision states, and runtime guidance.graduationPathTell the agent whether to prepare approval, request principal approval, collect receipts, reduce scope, run a dry run, or stop.Portable receiptsLet future decisions cite approval, refusal, correction, and execution receipts from the same action class.
Reference filesDiscovery manifest · Agent contract
Minimal integration
Wrap the boundary, not the whole product.
Call canExecute
Return allowed, allowed_with_constraints, review_required, deferred, blocked, or human_only from evidence, user approval, reversibility, and prior receipts.
Prepare before execute
If review is required, create a local approval packet with external_actions: 0. The agent can prepare; the human decides.
Record the receipt
Log what was approved, refused, revised, or executed. Use that receipt as future permission evidence.
Endpoint shape
The integration stays small.
Mission Gate wraps the execution boundary. It does not replace the model, runtime, IAM, policy engine, provider, or tracing stack.
const governedSend = wrapTool(sendGmail, {
capability: "email.send.external",
workspaceId,
gate,
tracer
})
try {
await governedSend.execute(input)
} catch (interruption) {
// show exact effect to the human
const result = await resumeUnderGrant({
interruption,
tool: sendGmail,
options: { gate, tracer }
})
verifyReceipt(result.receipt)
}Concrete packet
What an approval packet should contain.
A useful packet makes the proposed external consequence reviewable before the agent creates it.
Action class
email.send.external, repo.push, calendar.create, payment.initiate, etc.Proposed actionThe exact message, command, mutation, destination, or state change.
EvidenceRelevant context, prior receipts, user intent, risk, reversibility, and open questions.
DecisionAllowed, constrained, needs review, deferred, blocked, or human-only.
Receipt previewWhat will be recorded after approve, reject, revise, or execute.
The critique we want
Where should this live?
We are asking builders a narrow question: should action-class permission live in each app, in MCP, in evals/observability, or as a small receipt-based layer across them?
Builder askWhich action classes in your product should graduate by evidence instead of a binary allow/block permission?
MCP askShould tool discovery and invocation include action-class permission metadata?
Evals askShould supervised outcomes become permission evidence for future execution?
Security askWhat must be enforced architecturally instead of trusted to prompts?
Open loop
We want blunt builder feedback.
If you build agents, MCP servers, evals, coding tools, workflow automation, or enterprise AI controls, tell us where this pattern is wrong, redundant, or useful.