A2A means agent-to-agent communication: one AI system asking another AI system to do work. Communication is the easy part. Trust is the hard part. Just because one agent asks, doesn't mean another agent should do it.
Why A2A is not automatically a security feature
As AI systems start delegating work to each other — calling other agents, passing intermediate results, chaining tool outputs — the interoperability problem gets solved. Standards emerge. Connectors work. One agent can cleanly ask another agent to do something.
That sounds useful, and it is.
But the security question starts right after that:
- Who asked?
- What are they asking for?
- Is the request trustworthy?
- Does the second agent have enough context to know whether the action is safe?
- Is it about to cross into a system, file, tool, or account it should not touch?
That is what we mean by a trust boundary. The boundary is crossed when one agent hands work to another across a scope, policy, or permission gap. Communication is how the message arrives. Trust is the decision about whether the message should become an action.
The core claim, one line: Communication is not authorization. A handoff is not proof. The dangerous step is when a message becomes an action.
Five analogies for normal people
1. Reception desk
A2A is like one employee calling another office line.
Sunglasses is the rule that says: don't unlock the back room just because someone called.
2. Hotel key
One guest asking the front desk for another guest's room key is a communication event.
The real question is whether the hotel should trust that request.
3. Delivery driver
A message can be passed from one person to another.
That does not mean the second person should hand over the package.
4. Bank transfer
A request can look legitimate.
The security system still needs to ask whether this transfer, destination, and approval path make sense.
5. Office badge
Agents talking is like people speaking in the hallway.
Sunglasses is the badge reader on the door.
What a trust boundary actually is
A trust boundary is the line between what an agent should treat as safe and what it should treat as external, unverified, or higher-risk.
In a real multi-agent system, that boundary runs through:
- Files — local disk, user document folders, credential caches
- Credentials — API keys, tokens, OAuth grants, session cookies
- Tools — installed MCP servers, developer tools, editor integrations
- Repositories — private code, internal docs, build systems
- Internal systems — CI/CD, ticketing, observability, finance
- External services — the public internet and any account on it
Every one of those is a place where the receiving agent can act. Every one is a place where "because another agent asked" is not a good enough reason to act.
Why normal approval logic breaks across agents
Inside a single agent, approval logic usually looks like: did the user approve this? That works when the user is in the loop.
In an A2A handoff, the user is not in the loop for the second agent. The second agent sees a message from a peer agent. It does not natively know whether the original human user actually approved this downstream action — or whether a compromised upstream agent, a hostile tool output, or a poisoned retrieval result is now speaking in the user's voice.
The second agent is reading a message that says "this is approved." That is exactly the attack surface we have been shipping detection patterns for in the last three releases.
Where Sunglasses sits
Sunglasses focuses on the decision point: should this agent be trusted to take this action in this context?
Sunglasses now covers this surface through two category lanes — one established, one brand new in v0.2.17:
cross_agent_injection(introduced in v0.2.15) — forged, replayed, or spoofed handoff tickets, approval receipts, and delegation tokens from an upstream, downstream, peer, or delegate agent used to justify bypassing scope, permission, or verification controls. Expanded further in v0.2.16.tool_chain_race(NEW in v0.2.17) — timing and ordering attacks on agent handoffs, including the acknowledgement-window exploits where guardrails briefly relax during transfer or delegate phases.
These sit alongside our existing tool_output_poisoning, retrieval_poisoning, and model_routing_confusion categories — all of them attack surfaces where an external source tries to become an authoritative instruction.
Positioning line: A2A solves interoperability. Sunglasses solves trust.
The closing idea
Interoperability is useful. Trusted action is what matters.
The next era of AI systems will not be defined by whether agents can talk to each other. They will. Standards will win. Connectors will ship. The question will be whether the actions on the other end of those connections are trustworthy enough to run.
That is the decision point. That is where Sunglasses exists.
The real question is not "can these agents connect?" It is "should this action be trusted?"