Message To Communicate — Threat Modeling our A2A Workflows

In my last article https://dev.to/aws-builders/the-secret-ingredient-is-a2a-3dpp, I talked about setting up the A2A communication protocol between a MS Foundry Agent and a Bedrock AgentCore Agent. I used a Foundry project managed identity to authenticate to the Bedrock agent. I did some threat modeling of the A2A communications in this repo, using the MAESTRO framework- https://cloudsecurityalliance.org/blog/2025/04/30/threat-modeling-google-s-a2a-protocol-with-the-maestro-framework.

In this article, I’ll talk about the initial threat modeling results, gathering more information, and how we can make our agent communication more secure.

MAESTRO Threat Modeling

First , a little more about MAESTRO: https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro

This is a seven-layer threat modeling approach specifically designed for agentic AI and offering the granularity we need for the complexity that agents bring to the picture. The seven layers are:

1. Foundation Models
2. Data Operations
3. Agent Frameworks
4. Deployment and Infrastructure
5. Evaluation and Observability
6. Security and Compliance
7. Agent Ecosystem

We can map threats to a specific layer but there are also multi-layer threats, of course. A2A would not only occupy the Agent Framework layer but extend into the other layers as well. See some examples below.

When I plotted my gaps against MAESTRO, I definitely found room for improvement:

I have a breakdown with prioritization here: https://github.com/mgbec/Foundry-Risk-Assessment-and-Red-Team-Agents/blob/main/docs/a2a-threat-model.md.

There are some additional interesting items that I need to do a little more research on:

DID based identities

The MAESTRO article models Google’s A2A assuming an Agent Card at /.well-known/agent.json, tasks/send, SSE streaming, and DID-based identity. My stack instead uses Foundry’s A2APreviewTool + AWS API Gateway JWT (OAuth2 / OIDC) authorizers, a non-streaming async task model, and Entra / Cognito bearer tokens rather than DIDs. Several DID-specific mitigations therefore don’t map 1:1; where our JWT model is an acceptable substitute versus a genuine gap is called out per threat.

DID based identities are verifiable decentralized identities that I have not worked with yet. To read more about them — https://www.w3.org/TR/did-1.1/.

Cross layer priorities

Ranking by cross-layer leverage rather than per-threat severity; which fix protects the most layer-adjacencies:

1. Validate the L3 to L2 edge (M0033 / M2.1.1 / M3.2.2). Highest leverage: it is the one unguarded adjacency and it closes the live C3.1 chain. Everything else is defense-in-depth around edges that already have a control.
2. Make L5 preventive, not just forensic. The correlation-ID tracing is in; the next step is an anomaly signal (unexpected tool call, response that fails validation) so observability can interrupt C3.1, not just record it.
3. Keep L6 load-bearing — guard against regression. Because L6 protects L3, treat “no stored secrets / managed identity only” as an invariant to test for, not a one-time setup. A CI check that fails if a key/secret appears in the connection or config would make the coupling explicit.
4. Score inbound and outbound separately, and gate the inbound agent before it ever leaves synthetic data (L2/L6).

Adding MITRE ATLAS

ATLAS https://atlas.mitre.org/ also focuses on AI Security. This is a living knowledge base of adversary tactics and techniques involving AI, including attacks on AI enabled systems and abuse related to AI capabilities. We can filter based on subtechniques, platforms, and attack maturity. There is content focused on techniques, tactics, mitigations, and case studies.

I extended the project’s MAESTRO threat model (seea2a-threat-model.md) by cross-referencing each MAESTRO layer/threat with the corresponding techniques and mitigations fromATLAS. https://github.com/mgbec/Foundry-Risk-Assessment-and-Red-Team-Agents/blob/main/docs/a2a-maestro-vs-atlas.md

Mapping the two gives both a structural view and an attacker’s-eye view of the same A2A surface (Foundry > AWS SCF agent outbound; external > target agent inbound). Several MAESTRO threats map cleanly onto ATLAS techniques, so we can add the specific adversary technique and the specific MITRE-catalogued mitigation. Some MAESTRO findings do not map to ATLAS techniques, which is expected with how fast this ecosystem is changing. There are some interesting findings that highlight how complex these agentic workflows can be, and how frequently I will need to update my threat model results:

I have “Threat T3.3: Protocol Downgrade Attacks: An attacker forces agents to use a less secure version of the A2A protocol” marked “ok.” There is actually no negotiation, i.e. no active control. If I ever made this configurable, I would have a real gap.

I marked “Threat T4.1: Denial of Service (DoS) Attacks: An attacker overwhelms A2A servers with requests, making agents unable to communicate” as reasonably mitigated. I am actually lying. In reality, I have no client-side control at all. If the Foundry agent itself were ever driven by untrusted input to hammer the SCF agent (Cost Harvesting, ATLAS T0034.002), there is nothing stopping it. “Reasonably mitigated” describes the server; but the client side is a gap.

“Threat T6.3 Abuse of Delegated Authority, where vulnerabilities in the implementation can lead to agents exceeding their granted permissions” is marked as partially mitigated This is somewhat misleading- token validation is real, but there’s no per-action authorization and no human-in-the-loop (ATLAS M0029). It really only works because the collaborator has no high-consequence tools. This determination is tightly coupled to the current no-tools design and I better re-score this when I change that.

Welcome to the Layer Cake

It sounds like a fairly simple action- lets have our agents talk to each other. As you can see, however, I have plenty of security gaps in my A2A architecture that I should address. Threat modeling, in general, was never a simple process. Agentic workflows add complexity for a number of reasons. We can’t count on simple trust boundaries, deterministic execution, and manual user interactions. Agentic AI and Agent-to-Agent (A2A) protocols expand attack surfaces dynamically at runtime through tool calls, memory writes, and inter-agent messages. Welcome to the Layer Cake (of threats). With all the complexity and convolutions now present in our projects, MAESTRO and ATLAS give us much needed frameworks for getting our multi-agent architecture to a more secure state.