Skip to content

Signed Task Envelopes: Proving an AI Agent Meant to Make That Call

5 min read Fullmakt Team

  • business-case
  • authentication
  • agents
  • traceability
  • mcp
  • a2a
  • agentic-ai-gone-wrong

An agent holds a valid token. It calls a tool to refund order 1042. Somewhere between the model and the API, that request is captured, altered or simply replayed, and the refund runs three times, or for a different order.

Nothing about the token was wrong. It was valid, unexpired and correctly scoped. The token answered “who is calling?” and no one answered “is this the exact call the agent decided to make, once?”

This post covers that gap in agentic AI authentication, and how a signed per-call task envelope closes it for MCP and A2A tool calls.

The gap: identity is not intent

Bearer tokens and even sender-constrained tokens (see our post on DPoP for AI agents) bind a session to a client. They say nothing about an individual action. That leaves three failure modes:

  • Replay. A captured request is sent again. Without a single-use value, the broker can’t tell a retry from an attack. Related: accidental duplicates, as in idempotency and duplicate agentic actions.
  • Argument tampering. A proxy, plugin or compromised intermediary changes the arguments but keeps the authenticated session.
  • Confused deputy. A prompt-injected agent is tricked into calling a tool with attacker-chosen inputs. The call is authenticated, so it passes. See MCP confused deputy.

The fix is to make each call carry its own proof: signed by a key only the agent runtime holds, bound to this tool, these arguments and this moment.

What a task envelope contains

A task envelope is a short signed document (a compact JWS) sent alongside a tool call. In Fullmakt it travels in the X-Fullmakt-Envelope header and is signed with ES256 (ECDSA P-256). Its payload commits to:

  • the agent principal and the collection (the set of tools and credentials) it is calling,
  • the tool name,
  • a SHA-256 hash of the arguments,
  • a single-use nonce,
  • issued-at and expires-at times, with a lifetime of five minutes at most,
  • an optional parent envelope ID, linking a retry or follow-up to an earlier call.

The broker checks every field against the actual request. A mismatched tool, collection, principal or arguments hash is rejected, as is an expired envelope, a bad signature, or a nonce it has already seen. The agent’s public key is registered ahead of time, and a key containing private material is refused.

Why it helps beyond security

Traceability. Every executed call maps to one envelope ID, one nonce and one argument hash. In an incident you can show that the arguments the agent signed are the arguments the upstream API received. That is the evidence incident forensics usually lacks.

Approvals that mean something. When a risky call needs a human to approve it, the approval should cover exactly that action, once. With envelopes, the retry after approval references the approved call as its parent, and the approval is consumed on use. A different argument set doesn’t ride on someone else’s approval. This pairs with human-in-the-loop approval.

Delegation chains. In multi-agent systems, the parent link gives a verifiable lineage of who asked for what. See trace propagation across A2A and MCP.

What envelopes do not do

Be realistic about the limits:

  • They don’t stop a prompt-injected agent from signing a bad call. The agent runtime holds the key, so if the model is manipulated before signing, the envelope is faithfully signed. You still need policy, scoping and approval.
  • They don’t protect a stolen signing key. Keep it on the runtime, rotate it, and register only the public half.
  • They add work. The caller must produce a signature per call, and the broker must store nonces.

Treat envelopes as one layer: they prove integrity and uniqueness of an action, not that the action was wise.

How Fullmakt approaches it

Fullmakt is a credential broker for AI agents. Agents call it over MCP or A2A. It applies policy, attaches the upstream credential server-side so the agent never holds the secret, and writes an audit record per call.

  • Optional or required. Envelopes are verified when present. A principal can be flagged to require them, in which case unsigned calls are denied. Switch that on only after registering a real key, or the agent will lock itself out.
  • Single-use nonces are enforced per principal, so a replayed envelope is rejected as a replay.
  • Short lifetimes. The envelope window is capped at five minutes, with small clock-skew tolerance.
  • Clear failure reasons. A rejected call returns an explicit status such as expired, signature invalid, args hash mismatch or replay detected, which helps debugging and monitoring.
  • Launcher support. The bundled MCP launcher can generate a key, register its public half and sign envelopes for you.

The business case: for money-moving, data-deleting or regulated actions, you can tell auditors and customers that each agent action was individually attributable, tamper-evident and non-replayable, without giving the agent your credentials. See also our overview of audit controls for SOC 2.

Checklist

  • Does each agent call carry proof tied to its tool and arguments, or only a session token?
  • Can a captured request be replayed within the token’s lifetime?
  • Is an approval bound to one exact action and consumed once?
  • Where does the signing key live, and how is it rotated?
  • Can you show which signed envelope produced each upstream request?

FAQ

What is a task envelope for AI agents? A short-lived signed token attached to a single tool call. It commits to the tool, a hash of the arguments, a one-time nonce and an expiry, so the receiver can verify the call is exactly what the agent authorized.

How is it different from an OAuth access token? An access token identifies the client and its scopes for a period. An envelope authorizes one specific action once.

Does it prevent prompt injection? No. It prevents tampering and replay after the agent decides. Defend against injection with policy, least-privilege credentials and approvals.

Does it work with MCP and A2A? Yes. Fullmakt verifies envelopes on MCP tool calls. A2A management is handled through its own authenticated surface.

Is signing required? Not by default. You can require it per agent principal once a public key is registered.

What does Fullmakt cost? Usage-based pricing per operation, with no plans or minimums, plus a no-card sandbox for trying it with your own agents.