Mission Gate for builders

Wrap the provider call. Keep your agent stack.

Bind approval to the exact provider input, reject changed or reused grants, and record a result-linked receipt.

Start with the experimental @trust-graduation/core package. Run the synthetic checks locally without an API key or live provider.

Run the quickstart Read Trust Graduation
Run locally

Start with a result you can inspect.

Use Node.js 20+ in a new directory. These commands install the verified beta, create an adapter, and check it against a synthetic provider. No signup or credentials required.

Expected: CONFORMANCE_RESULT with "ok":true, nine passing checks, and two result-linked receipts. This proves the local adapter contract; it does not send a real message.

Connect your own provider · Explore the permission steps

mkdir mission-gate-trial
cd mission-gate-trial
npm init -y
npm install @trust-graduation/core@0.2.0-beta.4
npx trust-graduation init-adapter
npx trust-graduation conformance ./mission-gate-adapter.mjs --json

Keep the generated adapter. Your application supplies the trusted approval issuer, shared atomic grant store, provider function, and durable receipt sink.

Restart walkthrough

What survives when the process stops?

The source candidate kills real workers and restarts them against persisted state. It keeps the host journal, synthetic provider records, and receipts for inspection.

Run the recovery walkthrough · Review the draft implementation

Node.js 18+ on macOS or Linux; Windows via WSL. This source candidate is separate from the published beta. It uses a test approval authority and sends no messages.

Approval survivesA new process resumes the persisted decision; replay keeps the provider call count at one.
Receipt recoveredAfter provider acceptance and a lost reply, the host verifies provider evidence and reads back a separate receipt.
Denial recordedA denied request stays in failed[] and never reaches the provider.
Unknown stays visibleMissing confirmation requires reconciliation. Restarting does not silently resend.
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.

01

Define action classes

Examples: read.context, draft.compose, tool.call.local, email.send.external, repo.push, payment.initiate.

02

Bind the exact input

Use gate.prepare(action) to bind the target, canonical provider input, constraints, and expiry before review.

03

Authenticate approval

Your trusted approval host issues a grant for that binding. A chat reply or plain approval flag does not authorize execution.

04

Execute and verify

gate.execute() validates and consumes the grant before calling the provider. Persist the result-linked receipt and reconcile unknown outcomes.

Endpoint shape

The integration stays small.

Compose the adapter around your existing provider function. The four dependencies below belong to your application; the quickstart checks the same interface with synthetic dependencies.

import { createProviderGate } from "@trust-graduation/core";

const gate = createProviderGate({
  provider: yourExistingProvider,
  store: sharedAtomicGrantStore,
  authenticateGrant: verifyTrustedIssuer,
  writeReceipt: persistReceipt
});

const binding = gate.prepare(exactAction);
// Present this binding through your trusted approval host.
// Later, execute with its authenticated grant:
const result = await gate.execute({
  binding, approval, action: exactAction
});
// Inspect result.ok and result.reason before reporting success.

The helper's receipt is unsigned. Add your own signing and durable storage. Atomic grant consumption does not guarantee exactly-once external effects; crashes require provider reconciliation.

Concrete packet

What an approval packet should contain.

A useful packet makes the proposed external consequence reviewable before the agent creates it.

Action classemail.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.

Send a critique See Mission using it