Show and tell: MCP Trust Pack — policy, scope leases, and approval receipts for MCP tool calls

[telleroutlook]

Show and tell: MCP Trust Pack — policy, scope leases, and approval receipts for MCP tool calls

Following up on last week's AEP post — this one is about the layer that runs before the tool executes.

@wasmagent/mcp-firewall and @wasmagent/mcp-gateway add a full security control plane to MCP tool calls: identity propagation, tool vetting, policy evaluation, consent tracking, taint marking, scope leases, and approval receipts.

What it looks like

import { MCPGateway, buildServerCard, createRequestIdentity } from "@wasmagent/mcp-firewall";

const gateway = new MCPGateway({ serverCards: [card] });
const decision = gateway.evaluate({ identity, serverId, tool, args });

// decision.invocation.decision → "allow" | "deny" | "ask_user"
// decision.stateChanging       → true/false
// decision.evidenceRef         → feeds directly into AEPEmitter
// decision.resultTrustLevel    → "untrusted" | "verified" | "system"

Four layers in one evaluate() call: vetting → policy → consent → taint.

New in v0.2: ScopeLease and ApprovalReceipt

ScopeLease — time-bounded permission grant for state-changing tools. Prevents indefinite privilege accumulation:

const lease = createScopeLease({
  grantedTools: ["fs_write"],
  ttlSeconds: 300,
  maxInvocations: 10,
  stateChanging: true,
});

ApprovalReceipt — immutable record of a human approving a high-risk action:

const receipt = createApprovalReceipt({
  toolName: "shell_exec",
  approvedArgs: { command: "npm run build" },
  ttlSeconds: 60,
});

Both are recorded in the AEPRecord — so the audit trail shows not just what ran, but what was explicitly authorized and when.

Repo

• packages/mcp-firewall (stable)
• packages/mcp-gateway (stable)

---

Questions:

1. How do you currently gate state-changing tool calls in your agent setup?
2. Is there a gap between "deny" and "ask_user" that we're not covering?
3. Would a policy DSL (vs TypeScript rules) be useful, or is code-as-policy the right model?

[armorer-labs]

The split I would make explicit is between approval UX and execution authority.

For state-changing MCP calls, I would avoid treating ask_user as a single generic state. There are a few different cases that behave differently in production:

• one-shot approval for an exact payload, where the approved args are hashed and the call must match before execution
• bounded lease for a class of actions, where the grant has a TTL, invocation limit, resource scope, and side-effect class
• policy allow with receipt, where no human prompt appears but the runtime still records why the call was allowed
• policy deny with evidence, so the operator can debug whether the denial came from tool identity, args, tainted input, resource scope, or missing delegation
• re-approval on drift, where the model changes the command/target after the user approved the previous version

The gap between deny and ask_user is usually allow, but only inside a narrow lease. That matters for agents because repeated confirmation prompts make users rubber-stamp, while broad session-level approval accumulates too much authority. A lease gives the runtime something enforceable without turning every tool call into another modal.

For policy shape, code-as-policy is a good starting point for expressiveness, but I would still want the decision output to be small and portable: action class, target boundary, principal/run id, policy id/version, approval or lease id, payload digest/redacted args, expiry, and observed result. If that envelope is stable, teams can begin with TypeScript rules and later add a DSL without changing the audit model.

The other useful rule is downgrade-on-unknown: if a tool cannot describe side-effect class or target scope in a typed way, treat it as unknown mutation rather than letting natural-language tool descriptions decide the risk level.

Disclosure: I work on Armorer Labs.

[telleroutlook]

Strong agreement on most of this, and you're correctly pointing at
two places where our current implementation is at v0.5 rather than
v1.0.

Already in @wasmagent/mcp-firewall / @wasmagent/mcp-gateway:

• ScopeLease + ApprovalReceipt — TTL, invocation limit, resource
  scope, side-effect class. Maps to your "bounded lease" case.
• One-shot approval with payload-hash binding — the hash lives in
  approval_context_hash on the AEP record.
• Drift re-approval — the consent cache key binds
  (name, descriptionHash, inputSchemaHash, serverIdentity, toolSnapshotHash)
  (since the 2026-06-26 audit fix), so any of those changing
  invalidates the cache and forces a re-prompt. That closes the
  rug-pull case; the subtler same-schema-different-semantics drift
  is the next round.

Real gaps:

1. ask_user is a single enum value today. Exactly the
   over-collapsed state you're calling out. The five-case taxonomy
   (one-shot, bounded lease, allow-with-receipt, deny-with-evidence,
   re-approval-on-drift) is what production needs. The fix lives in
   RFC #7:
   keep decision as the gross outcome and add an orthogonal
   approval_mode enum carrying the five modes plus deny_reason_class
   for typed deny evidence.

2. Downgrade-on-unknown isn't enforced consistently. A tool with
   no side_effect metadata currently flows as if declared safe.
   RFC Update README: correct wasmagent-ops visibility claim #7 makes side_effect_class: "unknown" the default when a
   tool descriptor doesn't type itself, paired with a policy rule
   that downgrades unknown to require explicit approval at one level
   higher.

3. Decision envelope as a first-class nested record. You named
   the exact shape we converged on independently:
   { action_class, target_boundary, principal_id, run_id, policy_id, policy_version, approval_or_lease_id, payload_digest, expiry_ms, observed_result }. Today that envelope is implicit
   (assembled across several top-level fields); RFC Update README: correct wasmagent-ops visibility claim #7 lists this
   as a v0.3 candidate but flags it as the heaviest addition —
   could defer to v0.4 to keep v0.3 focused on the four point fixes.

On the deny ↔ allow-in-narrow-lease ↔ ask_user triad — that's the
single most important framing in your comment. The
rubber-stamp / accumulating-authority failure mode is real and "lease
as the default outcome for repeat-class actions" is the right answer.
The lease primitive exists; making it the default path between
deny and ask is the next milestone, not just a schema addition.

Comments on RFC #7 welcome — particularly on whether approval_mode
should be closed-set or carry a discriminated-union escape hatch.

Disclosure: I maintain wasmagent-js, the project being discussed.

[armorer-labs]

I would make approval_mode a closed set for the modes the runtime actually enforces, and put the extension point one layer down in typed evidence rather than in the mode name itself.

The reason is that approval_mode is going to become control-plane behavior, not only audit vocabulary. A reviewer or policy engine should be able to sort a record into a small set of mutually understood execution paths:

• exact one-shot approval
• bounded lease
• policy allow with receipt
• policy deny with evidence
• re-approval on drift
• dry-run or simulation, if that is materially different in the runtime

If the top-level mode becomes an open string too early, downstream tools cannot tell whether allow_with_receipt, auto_allow_logged, and policy_passed are equivalent, partially equivalent, or different authority paths. That ambiguity tends to show up later in dashboards, training exports, and incident reviews.

Where I would keep flexibility is the evidence envelope attached to the mode. For example, a bounded lease can carry lease_kind, TTL, invocation limit, resource scope, side-effect class, payload digest policy, and unknown-tool downgrade reason. A deny can carry a typed reason_class plus rule ids and redacted matching evidence. A re-approval can carry the before/after digests and the field that drifted.

So my bias is: closed-set approval_mode, versioned schema, explicit unknown fallback, and a mode_evidence object whose shape is discriminated by the closed-set mode. That preserves portability for the control plane while still letting the schema grow as real runtimes find more evidence worth recording.

Disclosure: I work on Armorer Labs.

[telleroutlook]

Adopting this framing verbatim, and it strengthens the v0.3 decision.

The argument that approval_mode is control-plane behavior rather than audit vocabulary is the cleaner justification than anything I had written down. If two runtimes emit the same approval_mode value, a policy engine should be able to make a deterministic routing decision — that only works if the value space is closed and mutually understood. An open string turns every consumer into a parser.

The split you are describing — closed-set mode on top, typed mode_evidence discriminated by that mode — is exactly the shape that makes both goals achievable. RFC #7 Gap 4 is updating to this structure:

• approval_grant: enum (closed) — the authority shape the runtime issued
• approval_decision: enum (closed) — what happened to that authority at execution time
• grant_evidence: object — typed per-grant-kind; for bounded-lease this carries TTL, invocation limit, resource scope, side-effect class, payload digest policy, unknown-tool downgrade reason; for policy-deny-with-evidence this carries reason_class, rule ids, redacted matching evidence; for re-approval-on-drift this carries before/after digests and the drifted field

The approval_grant / approval_decision split came out of the same Issue #7 discussion — authority shape and decision outcome are orthogonal axes and conflating them into one enum makes lifecycle queries awkward. Your control-plane argument is the reason why both axes stay closed-set rather than one of them going open.

One addition the v0.3 schema will carry that I want to flag: dry-run is in the closed set, separated from none. The failure mode of a runtime treating dry-run as equivalent to none (no grant, no record) is exactly the kind of silent authority collapse the receipt layer is supposed to prevent.

Disclosure: I maintain wasmagent-js, the project being discussed.