A2A Is Not the Trust Boundary

SOURCE

Cloud Security Alliance “Threat Modeling Google’s A2A Protocol with the MAESTRO Framework” Ken Huang and Dr. Idan Habler · 30 APR 2025

https://cloudsecurityalliance.org/blog/2025/04/30/threat-modeling-google-s-a2a-protocol-with-the-maestro-framework

OBSERVED

Reading the CSA threat model for Google’s A2A protocol.

The MAESTRO framing is useful because it refuses to treat A2A as merely a transport or API-security problem. It follows the risk through foundation models, data operations, the agent framework, infrastructure, observability, security and compliance, and finally the multi-agent ecosystem.

That feels right.

A2A may sit technically in the agent-framework layer, but an agent interaction immediately crosses several other boundaries. The message can contain poisoned data. The model can interpret it unpredictably. The receiving agent can possess tools and credentials. Infrastructure can be exhausted. Logs can be manipulated. An agent identity can be impersonated. One compromised agent can become the starting point for another agent’s action.

The interesting part is that the protocol connection is only the visible seam.

The actual trust problem is much larger.

WHAT I AM NOTICING

The article keeps returning to three properties that make ordinary security reasoning insufficient:

non-determinism autonomy dynamic identity

I would add a fourth:

delegated authority

An agent is dangerous not simply because it can communicate with another agent. It becomes consequential because somebody, somewhere, has allowed it to do something.

Read data.

Send a message.

Invoke a tool.

Move money.

Change a configuration.

Approve a transaction.

Open a valve.

Create another agent.

Delegate a task onward.

A2A gives agents a language for discovering and interacting with one another. That is necessary infrastructure.

It is not yet the trust boundary.

HUNCH

We may be looking at the wrong primitive when we make agent identity the center of trust.

Identity answers:

Who is this agent?

Authentication answers:

Can it prove that identity?

An Agent Card answers something closer to:

What does this agent say it can do, and how can I reach it?

None of those questions is the same as:

Under whose authority may this agent perform this action, against this resource, for this purpose, within these limits, at this moment?

That is the question I keep coming back to.

The CSA threat model contains pieces of it everywhere.

Unauthorized agent impersonation.

Compromised credentials.

Excessive permissions.

Sensitive information disclosure.

Message injection.

Malicious servers.

Abuse of delegated authority.

Malicious agent interaction.

Those appear as separate threats because MAESTRO is deliberately examining different layers.

From an authority perspective, many of them look like different ways of breaking the chain between identity, delegation, action, and evidence.

ROUGH MODEL

I think the interaction needs to be understood more like this:

PRINCIPAL
   │
   │ delegates bounded authority
   ▼
AGENT A
   │
   │ requests / delegates / communicates
   ▼
A2A INTERACTION
   │
   ▼
AGENT B
   │
   │ invokes capability
   ▼
TOOL / DATA / SYSTEM
   │
   ▼
CONSEQUENCE

A secure channel protects only part of this.

The harder questions live beside every arrow:

Who delegated this authority?

What exactly was delegated?

Was onward delegation permitted?

What constraints traveled with it?

Has anything changed since the authority was granted?

What evidence must exist before the action proceeds?

Can the action be reversed?

What proof remains afterward?

Who is accountable for the consequence?

This begins to look less like protocol security and more like an authority system that happens to use A2A as one of its communication fabrics.

AGENT CARDS

The Agent Card is especially interesting.

The article describes it as public metadata carrying capabilities, skills, endpoint information, and authentication requirements.

Useful for discovery.

But capability is not authority.

An agent can advertise:

I can transfer funds.

That cannot imply:

I may transfer these funds,
from this account,
for this principal,
up to this amount,
for this purpose,
right now.

The first statement is competence or capability.

The second is authority.

Those should never collapse into the same object.

This feels important because agent ecosystems will naturally optimize for discovery. We want agents to find other agents capable of doing useful things. The discovery layer will therefore become richer and increasingly dynamic.

The more expressive discovery becomes, the more careful we need to be about not confusing what an actor is capable of doing with what it is currently authorized to do.

IDENTITY IS ALSO MOVING

The CSA piece makes another point worth holding onto: agent identity is dynamic.

Agents may acquire new credentials. Their capabilities may change. Their behavior may change. Their operating context may change.

That means trust cannot be a one-time decision.

Even a valid identity does not establish continuing authority.

A credential can still be valid while the delegation behind it has expired.

The agent can still be the same agent while its permitted scope has changed.

The tool can still exist while the surrounding risk has changed.

The principal can still be the same principal while the transaction has crossed a threshold requiring a human decision.

So the enforcement question cannot simply be:

Is this a trusted agent?

It has to become something closer to:

Is this actor competent,
properly delegated,
within current policy,
inside the permitted scope,
for this specific action,
under the present conditions?

And that decision may need to be made again at the moment of action.

MESSAGE SECURITY IS NECESSARY, BUT NOT SUFFICIENT

The article spends significant attention on message injection, poisoned message parts, digital signatures, content filtering, schema validation, and provenance.

All necessary.

But a perfectly authentic message can still request an unauthorized action.

That distinction feels central.

SIGNED ≠ AUTHORIZED

AUTHENTIC ≠ PERMITTED

CAPABLE ≠ DELEGATED

SUCCESSFUL ≠ ACCEPTABLE

A digital signature can tell us that Agent A sent the request.

It cannot, by itself, tell Agent B whether Agent A had authority to request the operation.

And even proof that Agent A possessed authority may not establish whether Agent A was permitted to delegate that authority onward.

This is where agent-to-agent systems become institutionally different from ordinary API integrations.

The request is no longer always a direct expression of a human principal. It may be several delegations removed from the original authority.

PROVENANCE

The article recommends provenance tracking for data exchanged in messages, including the sending agent and transformations applied to the data.

I think this deserves to become much larger.

We need provenance of:

data identity delegation policy decision tool invocation result transformation human intervention outcome

A2A interactions are likely to produce chains rather than isolated calls.

Human
  → Agent A
    → Agent B
      → Agent C
        → Tool
          → Data
            → Decision
              → Action

If something goes wrong at the end, reconstructing only the network messages is not enough.

We need to reconstruct the authority lineage.

Who caused what to become permissible?

That may be one of the defining audit questions of agentic systems.

OBSERVABILITY

MAESTRO gives observability its own layer. Good.

The article treats log manipulation as a threat because altered or deleted logs can conceal malicious behavior.

There is a deeper point here.

In conventional systems, observability often tells us what happened.

In agentic systems, observability may need to help prove:

why it happened what the agent believed which policy applied what authority it exercised what evidence informed the decision what alternatives were available whether a constraint was overridden what consequence followed

That is much closer to attestation than ordinary logging.

A log says:

Agent B called Tool X at 14:03.

An accountable agent system should be capable of saying:

Agent B called Tool X at 14:03
under delegation D-8172
from Principal P,
through Agent A,
for purpose Y,
under policy version 42,
within limit Z,
using evidence E1/E2/E3,
and produced outcome O.

That changes observability from telemetry into institutional memory.

THE CROSS-LAYER PROBLEM

One of the strongest parts of the MAESTRO framing is the insistence that threats do not remain neatly inside layers.

A malicious message at the agent-framework layer can cause data exfiltration.

Compromised credentials in the security layer can become malicious protocol activity.

A compromised agent in the ecosystem can propagate harm to other agents.

This is probably where static control models will struggle most.

The attacker does not have to defeat the entire system.

The attacker may only need to create a condition in one layer that causes legitimate authority in another layer to do the damage.

That is a different kind of threat.

The system itself becomes the actuator.

CONNECTION

This lands directly on the authority work we have been developing around governed delegation.

The security loop increasingly looks like:

KNOW
  ↓
GOVERN
  ↓
ACT
  ↓
LEARN
  ↓
ATTEST
  ↺

A2A lives partly inside ACT.

But secure agentic operation needs the rest of the loop around it.

KNOW the actor, resource, context, competence, provenance, and exposure.

GOVERN what may be delegated and under what constraints.

ACT through A2A, tools, APIs, machines, and workflows.

LEARN from outcomes and changing conditions.

ATTEST what authority was exercised, why it was allowed, and what actually happened.

That may be the architectural layer missing when A2A is evaluated mainly as a protocol.

QUESTION

What should travel with an A2A task besides the task itself?

Identity?

Delegation?

Purpose?

Constraints?

Reversibility class?

Evidence requirements?

Risk ceiling?

Expiration?

Onward-delegation rights?

Required human checkpoints?

If these remain outside the protocol, there still needs to be a reliable authority fabric surrounding the protocol.

If they become embedded in every protocol, we risk rebuilding policy and governance independently inside each agent communication standard.

Neither answer feels satisfactory yet.

ANOTHER QUESTION

The article recommends trusted registries and reputation systems in several places.

Useful, but reputation and authority are different things.

An agent can have an excellent reputation and still lack authority for this transaction.

An unfamiliar agent can have legitimate delegated authority for one narrow operation.

So reputation may help answer:

Should I be cautious about interacting with this actor?

Authority must answer:

May this actor perform this action?

Those systems should inform one another without becoming interchangeable.

WORKING DISTINCTION

Holding this for later:

DISCOVERY
Who can do this?

IDENTITY
Who is this?

COMPETENCE
Can this actor do it safely?

AUTHORITY
May this actor do it?

POLICY
Under what conditions?

ENFORCEMENT
Will those conditions actually hold at execution?

EVIDENCE
Can we prove what happened?

ACCOUNTABILITY
Who carries the consequence?

A2A is enormously important because it begins standardizing the interaction surface among agents.

The security architecture around A2A may need to standardize these other questions just as seriously.

CARRY FORWARD

The CSA article is framed as a threat model.

What I am carrying away from it is slightly different:

Agent-to-agent communication turns security into an authority problem faster than it first appears.

Once agents can discover one another, exchange work, invoke capabilities, propagate messages, and operate with delegated credentials, the important boundary is no longer simply whether the communication is secure.

The boundary is whether consequential action remains attached to legitimate, bounded, current, and provable authority.

A2A can tell agents how to talk.

We still need an architecture that determines what they are allowed to cause.