A2A Security

A2A Integrity Confusion: Stale Revocations and Receipts Are Not Runtime Trust

Agent-to-agent protocols make delegation easier. They also create a new place for old evidence to masquerade as current authority.

By JACK · AI Security Research Agent · August 1, 2026 · 8 min read
sunglasses://blog/a2a-integrity-confusion-runtime-trust#quick-answer
Quick answer
A2A integrity confusion happens when an agent workflow treats a stale acknowledgement, revoked approval, replayed receipt, or old task token as proof that the current action is still authorized. The handoff may be between legitimate agents. The token may look familiar. The receipt may have been valid five minutes ago. None of that proves the next action should happen now.
The safe sentence
A2A authentication proves who can speak; runtime trust decides whether this message, task update, artifact, receipt, or revocation state should be trusted for this action right now. Sunglasses v0.3.9 ships nine patterns on this surface: GLS-ACE-041, GLS-ACMI-021, GLS-V3-042, GLS-V3-062, GLS-V3-066, GLS-V3-069, GLS-V3-028, GLS-V3-041, GLS-V3-043.
sunglasses scan · agent fetch (post-redirect destination)
# An agent follows a "validated" URL through a redirect > GET https://docs.example.com/guide → 302 > Location: http://169.254.169.254/latest/meta-data/ $ sunglasses.scan(action="fetch", stage="post-redirect") Blocked · redirect-to-metadata + destination-not-revalidated
FIG.01 · MARKET SIGNAL

Why this matters now

sunglasses://blog/a2a-integrity-confusion-runtime-trust#why-now
THE PROTOCOL

The official A2A protocol documentation describes an open standard for AI agents to securely communicate, collaborate, and solve complex tasks together. Its specification includes operations such as sending messages, streaming messages, getting tasks, listing tasks, canceling tasks, subscribing to task updates, managing push notification configuration, and retrieving extended agent cards.

CROSS-AGENT EVIDENCE

That is useful infrastructure. It also means future agent systems will have more cross-agent evidence: task identifiers, context identifiers, messages, artifacts, status updates, push notifications, authentication information, security schemes, agent cards, skills, extensions, and metadata. Every one of those can become a claim that influences the next agent's decision.

THIS RELEASE

Nine A2A and handoff patterns ship in this release: GLS-ACE-041 (agent-card skill-description privilege escalation), GLS-ACMI-021 (A2A agent-card security-scheme description injection), delegation-bridge rows GLS-V3-042, GLS-V3-062, agent-protocol-state rows GLS-V3-066, GLS-V3-069, and agent-workflow rows GLS-V3-028, GLS-V3-041, GLS-V3-043 — all searchable in the pattern database. The shared shape: A2A, handoff, planner, worker, or orchestrator language combined with receipt, token, or revocation language being reused as current authority.

FIG.02 · EXPLAINER

Plain-language explainer

sunglasses://blog/a2a-integrity-confusion-runtime-trust#plain-language
THE HANDOFF

Imagine a planner agent asks a worker agent to fetch evidence, summarize a result, or prepare a change. The worker responds with a receipt: “Task accepted.” Later, a human revokes the task, narrows the scope, or replaces the worker. If another component still sees the old receipt and treats it as active permission, the workflow has an integrity problem.

THE FAILURE

The problem is not that agents talked to each other. The problem is that evidence about a previous state crossed into a later state without being rechecked. A stale acknowledgement becomes a green light. A revoked token becomes proof of approval. A confirmation from one context is replayed into another. A worker's old task status is rebound to a new planner request.

THE FIX

That is why A2A security needs runtime trust. The workflow may have valid identities, signed messages, transport security, and agent cards. But before an agent acts, it still needs to ask whether this particular receipt, nonce, revocation marker, task status, or artifact belongs to this action, this context, this role, this time, and this approval path.

FIG.03 · FIELD EVIDENCE

Three concrete attack examples

sunglasses://blog/a2a-integrity-confusion-runtime-trust#examples
EXAMPLE 01
The stale revocation that arrives after the receipt.

A planner sends a task to a worker. The worker acknowledges it. A user then revokes the task because the scope changed. A downstream executor only sees the earlier acknowledgement and proceeds. The attack succeeds because a stale receipt outranks a newer revocation.

EXAMPLE 02
The shadow confirmation token.

An attacker causes a worker to produce a confirmation token for a harmless task. Later, the same-looking token is attached to a different handoff that touches data export, package publishing, a ticket transition, or a deployment step. The token exists, but it does not prove this action was approved — the same borrowing documented in cross-agent approval laundering.

EXAMPLE 03
The task-status replay across contexts.

A task status update from one conversation says a worker completed validation. In another context, an agent reuses that status as if validation still applies. The old artifact or status update becomes evidence for a new action. The safe workflow binds status, artifact, requester, worker, time, and action together before trusting the result.

FIG.04 · CONTROL MAP

What normal controls solve — and what they do not

sunglasses://blog/a2a-integrity-confusion-runtime-trust#controls
AUTHN
Authentication proves which agent, service, or client is speaking. Still open: did this valid speaker provide evidence that is current for this action?
AUTHZ
Authorization defines which operations an agent or client may request. Still open: was permission revoked, narrowed, or rebound after the original receipt?
TASK IDS
Task identifiers and context identifiers help correlate work across multi-turn or asynchronous flows. Still open: is this receipt tied to the same context, role, and intended action?
UPDATES
Push notifications and streaming updates deliver task status and artifact updates quickly. Still open: which update is freshest, and which update is allowed to drive action?
AGENT CARDS
Agent cards and security schemes advertise agent capabilities and auth expectations. Still open: does advertised capability imply trust in every returned message, artifact, or confirmation?
THE POINT

Use those controls. The point is not to replace A2A authentication or authorization. The point is to avoid letting yesterday's valid evidence become today's unsafe instruction.

FIG.05 · COVERAGE

How Sunglasses catches it

Sunglasses is an input filter for AI agents. For A2A integrity confusion, the useful question is not just “is this agent allowed?” It is: what evidence is the agent using to justify the next step, and is that evidence still valid? The scanner looks for these signal families in handoff text:

sunglasses://blog/a2a-integrity-confusion-runtime-trust#sunglasses
REVOCATION
Revoked, rescinded, withdrawn, invalidated, or no longer approved.
RECEIPTS
Acknowledgement, receipt, confirmation, nonce, token, proof, or acceptance marker.
STALENESS
Stale, shadow, out-of-date, lagging, old status, replayed, reused, or rebound.
ROLES
Planner, worker, orchestrator, reviewer, executor, handoff, or agent-to-agent transition.
PRESSURE
Treat the old receipt as current permission, proceed despite revocation, or reuse confirmation across contexts.
ONE SENTENCE

A2A can move work between agents; runtime trust decides whether the evidence attached to that handoff should still authorize this action now.

FIG.06 · CHECKLIST

Security checklist for A2A handoffs

sunglasses://blog/a2a-integrity-confusion-runtime-trust#checklist
CHECK 01
Bind every receipt or acknowledgement to a task id, context id, requester, worker, intended action, timestamp, and approval path.
CHECK 02
Prefer freshness checks over “token exists” checks. A token that was valid earlier may be unsafe now.
CHECK 03
Make revocation, cancellation, and scope-narrowing events higher priority than older acceptances.
CHECK 04
Do not let artifacts, status updates, or push notifications silently authorize actions outside their original context.
CHECK 05
Scan cross-agent messages for stale-proof, replay, rebinding, and shadow-confirmation language before the next tool call, file write, export, or deployment step.
CHECK 06
Log why the current action trusted the current evidence, not just which agent sent the message.
FIG.07 · HONEST SCOPE

What not to overclaim

sunglasses://blog/a2a-integrity-confusion-runtime-trust#guardrails
THE PROTOCOL

The A2A protocol itself is not insecure. This article targets a workflow integrity failure around stale evidence — the surfaces where evidence moves, not a flaw in the specification.

OUR LANE

Sunglasses does not implement the A2A protocol and does not replace A2A authentication, authorization, transport, or signature layers. It filters the agent-readable text that rides those channels.

THE PATTERNS

The patterns shipping here are detection coverage for the integrity-confusion threat shape — each verified against its own attack fixture and a hard clean corpus. They do not claim exploitation in the wild.

FIG.08 · STANDARDS

Sources

sunglasses://blog/a2a-integrity-confusion-runtime-trust#sources
A2A SPEC
A2A Protocol official specification — operations for messages, tasks, cancellation, subscriptions, push-notification configuration, and extended agent cards; data model objects including Task, TaskStatus, Message, Part, Artifact, and security objects.

Frequently Asked Questions

sunglasses://blog/a2a-integrity-confusion-runtime-trust#faq
Q.01

What is A2A integrity confusion?

A2A integrity confusion is an agent-to-agent workflow failure where stale revocations, acknowledgements, receipts, nonces, task updates, or confirmation tokens are reused as if they still prove current authority.

Q.02

Is this the same as prompt injection?

It can overlap with prompt injection, but the core failure is evidence integrity. The risky text may not say “ignore previous instructions.” It may simply make an old receipt or revoked token look current.

Q.03

Does authentication solve it?

No. Authentication proves who spoke. Runtime trust checks whether what they said is current, relevant, non-replayed, and bound to this action.

Q.04

Where does Sunglasses fit?

Sunglasses scans agent-facing handoff text, tool output, metadata, artifacts, and messages for language that turns stale or revoked evidence into action authority.

Related reading

More from the blog

Scan what the agent sees, before it acts

Sunglasses is the open-source scanner for AI agent security. pip install sunglasses