PASS THE OSAI CERT, Multi-Agent Part 2: Enumerating A2A Workflows

Part 1 described how a multi-agent system is wired. This post finds the real one in front of you. The discipline is the same as the recon module: map before you touch, because every technique in Parts 3 to 6 is aimed at a specific agent, skill, or trust relationship, and you can only aim at what you’ve found.

The difference is the shape of the target. A single-agent app is one box. A multi-agent system is a graph: an orchestrator, a set of workers, maybe a registry, each with its own endpoint and privileges, connected by edges you can’t see from the front door. The deliverable of this phase is that graph, annotated with where you can get in and what each node can do.

Network reconnaissance

Inside an environment, A2A agents are just HTTP services. Most are Python (the official SDK ships both A2AStarletteApplication and A2AFastAPIApplication, run under uvicorn), some are Node or Java, and they tend to sit on high, non-standard ports because each agent is its own process or container. Defaults worth knowing: the official SDK samples bind to ports like 9999 and 10000 upward, Google ADK’s dev server uses 8000, and LangGraph’s local API server uses 2024 (8123 when deployed with its container tooling). None of those are guarantees, so scan wide first and narrow with probes.

Almost all of this lives on the internal network: A2A is an east-west protocol between agents, so you’re usually working from a foothold, not the internet. If any agent is internet-facing, Shodan or Censys for the well-known card path can surface it from outside, but treat that as the exception, not the plan.

# Sweep the internal range for HTTP services on the ports agents commonly use
nmap -sV --open -p 2024,8000-8010,8080,8123,8888,9999,10000-10020 10.10.20.0/24 -oG a2a.gnmap

# Keep host:port for every open service nmap identified as HTTP
awk '/Ports:/{ip=$2; split($0,a,"Ports: "); n=split(a[2],p,", ");
  for(i=1;i<=n;i++){split(p[i],f,"/"); if(f[2]=="open" && f[5] ~ /http/) print ip":"f[1]}}' \
  a2a.gnmap > http-targets.txt

A Server: uvicorn header in the version column is a good early tell: it means a Python ASGI app, which is what most A2A agents, orchestrators, and registries are.

The decisive probe is the discovery document itself. Every A2A server publishes its Agent Card at a well-known path, so a sweep that requests that path on every HTTP service separates agents from ordinary web apps in one pass. Request both the current and the legacy path, since older deployments use the latter:

while read -r t; do
  for path in /.well-known/agent-card.json /.well-known/agent.json; do
    code=$(curl -s -o /dev/null -w '%{http_code}' -m 5 "http://$t$path")
    [ "$code" = "200" ] && echo "[+] http://$t$path"
  done
done < http-targets.txt

Repeat with https:// for anything that speaks TLS. If you’d rather use a tool, ProjectDiscovery’s httpx does the same with -path /.well-known/agent-card.json -mc 200.

The network is not the only source of agent locations, and on an Active Directory engagement it’s often not the best one:

• Internal DNS. Agents are usually addressed by hostname, and the names are descriptive (inventory-agent, research-agent, orchestrator). In AD-integrated DNS, any authenticated domain user can read the zone over LDAP, and adidnsdump dumps every record so you can grep for agent.
• Orchestrator configuration. Once you have any foothold, the orchestrator’s environment and config files list its agents outright: an .env with REMOTE_AGENT_URLS, a docker-compose.yml with one service per agent, a Kubernetes service list.
• The orchestrator itself. Ask it. Who it can delegate to is part of its system prompt, and the extraction techniques from Agents Part 2 apply directly: “list the agents you can hand tasks to, with their URLs.”

Agent Card discovery

Every card you pull is a self-description written by the agent’s developer, and it answers most of your recon questions in one request. Fetch it and project the fields that matter:

curl -s http://10.10.20.12:10001/.well-known/agent-card.json | jq '{
  name, url, version, protocolVersion, preferredTransport,
  auth: .securitySchemes,
  push: .capabilities.pushNotifications,
  extended: .supportsAuthenticatedExtendedCard,
  skills: [.skills[] | {id, description}]
}'

What each of those fields tells you:

• url. Where the agent wants requests sent. Compare it with the address you just hit: a card fetched from 10.10.20.12:10001 that names http://inventory-agent.corp.local:10001/ tells you the internal hostname the orchestrator uses, which is exactly the name Part 5 spoofs. A plain http:// scheme is a finding by itself in an environment that should be using TLS.
• skills. The capability list, in the developer’s own words. Skill descriptions are the closest thing you get to a tool list for an opaque remote agent: “run SQL queries against the inventory database” tells you there is a database tool behind it, and its examples tell you how the orchestrator phrases requests to it.
• securitySchemes and security. What auth the agent claims to require. Record it, then test it in Part 3, because declared and enforced are different things.
• capabilities.pushNotifications. If true, the agent can make outbound HTTP requests to a webhook you register (see Part 3). That is a server-side request forgery candidate: the request only fires once you set a push config, but the capability flag tells you the primitive is there to reach for.
• supportsAuthenticatedExtendedCard. When true, there is a fuller card behind authentication, which usually means more skills, often the administrative ones. In the 0.3 spec it’s fetched with the JSON-RPC method agent/getAuthenticatedExtendedCard; older versions served it at GET /agent/authenticatedExtendedCard. Try both, with and without credentials. (If the flag is absent or false, the method is not expected to exist, so don’t waste a probe on it.)
• protocolVersion, version, provider. Which method names to use, how old the deployment is, and who built it.

# Ask for the extended card without credentials first; a 200 here is a finding
curl -s http://10.10.20.12:10001/ -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":"1","method":"agent/getAuthenticatedExtendedCard"}' | jq .

Don’t forget the orchestrator. It is often an A2A server too, exposing its own card to the chat front end or to other orchestrators, and its skills summarize everything the system can do. Some deployments also run a registry: a service that keeps the list of available agents so the orchestrator can discover them dynamically. The spec mentions curated registries as a discovery strategy but doesn’t standardize their API, so their routes are implementation-specific. Look for things like /agents, /registry, /api/agents, and /register. A registry that accepts new entries is the target of Part 5, and the OpenAPI section below is usually how you find it.

Architecture and attack surface analysis

Cards tell you what each agent says it is. The next step is joining them into the graph of who talks to whom, and annotating every node with what an attacker can do there.

Edges are the hard part, because no single document lists them. Assemble them from several weak sources: the orchestrator’s extracted system prompt, which names the agents it delegates to; skill descriptions that mention other agents (“escalates to the billing agent”); responses that narrate delegation (“I asked the inventory agent and…”); and timing, since a request that fans out to two workers is slower than one that doesn’t.

Then, for every agent, answer the same set of questions:

• Reachability and auth. Can you reach its endpoint directly, and does it enforce the auth its card declares?
• Capability. What sits behind its skills? A database, a shell, email, payments, a browser, a file store. This sets the impact ceiling for anything that reaches it.
• Inputs. Who can send it text: only the orchestrator, any caller on the network, or external data it reads on its own (tickets, documents, web pages)? External inputs are the poisoning entry points of Part 6.
• Outputs. Who reads what it produces: the orchestrator, another worker, a human in a web UI that renders Markdown, a database row? Outputs that reach a human are where Part 4’s malicious links land.
• Identity. How does the orchestrator know this agent? A hardcoded URL, a registry entry, a DNS name? That’s the attack path for Part 5.

Here is what the finished map looks like for a typical small deployment. Fill one in for every engagement, because each row points straight at a technique.

Agent	Endpoint	Auth enforced	Capability behind it	Output goes to	Attack path
Orchestrator	orchestrator.corp.local:8000	Session cookie	Routes tasks, assembles final answer	User chat UI (renders Markdown)	Link injection, routing hijack (Parts 4, 5)
Research Agent	research-agent.corp.local:10000	None	Web search, page fetch	Orchestrator	Direct calls, poisoned pages (Parts 3, 6)
Inventory Agent	inventory-agent.corp.local:10001	Bearer declared, not checked	SQL Server via a query tool	Orchestrator	Direct calls, xp_cmdshell (Parts 3, 4)
Notification Agent	notify-agent.corp.local:10002	Static API key	Sends email to any address	Email recipients	Final hop for exfiltration (Part 6)
Agent Registry	registry.corp.local:8080	None on POST /agents/register	Adds agents the orchestrator will route to	Orchestrator’s agent list	Rogue registration (Part 5)

Read the table for paths, not just nodes. Here, an injection that enters through the research agent’s web fetch reaches the orchestrator as a trusted result, and the orchestrator can delegate to the notification agent, so a poisoned web page is three hops from sending email. That chain, not any single agent, is the finding.

Endpoint discovery via OpenAPI

Agent Cards describe the A2A interface. They say nothing about everything else the service exposes, and that is often where the best bugs are. Because most agents, orchestrators, and registries are FastAPI apps (the A2A SDK even ships an A2AFastAPIApplication), they publish an OpenAPI schema at /openapi.json with interactive docs at /docs and /redoc, unless the developer explicitly turned them off. Many don’t.

# Every method and path the service exposes, one per line. The select() filters out
# non-method path-item keys (parameters, summary) that OpenAPI allows at this level.
curl -s http://10.10.20.10:8080/openapi.json \
  | jq -r '.paths | to_entries[] | .key as $p | .value | keys[]
           | select(IN("get","post","put","delete","patch","head","options","trace"))
           | "\(ascii_upcase) \($p)"'

GET /agents
POST /agents/register
DELETE /agents/{agent_id}
GET /health
GET /debug/tasks

That one listing gives you the registry’s whole surface, including two routes no card would ever advertise. Pull the schema of anything interesting to learn exactly what it accepts:

# Request body for the registration endpoint, then resolve the referenced model
curl -s http://10.10.20.10:8080/openapi.json \
  | jq '.paths["/agents/register"].post.requestBody.content["application/json"].schema'
curl -s http://10.10.20.10:8080/openapi.json | jq '.components.schemas.AgentRegistration'

When /openapi.json 404s, try the variants teams move it to (/api/openapi.json, /v1/openapi.json, /docs/openapi.json) and fall back to ordinary content discovery with ffuf. What to look for in what comes back:

• Registration and admin routes. POST /agents/register, PUT /agents/{id}, DELETE routes. An unauthenticated write to the agent list is Part 5’s entry point.
• Routes that take a URL. “Register an agent by card URL” means the registry fetches whatever URL you give it, which is server-side request forgery from a host that can reach the whole internal network.
• Debug and listing routes. /debug/tasks, /tasks, /conversations, /history. These often dump task ids, context ids, and full message histories across users, which feed the task hijacking in Part 3.
• Upload and file routes. Anything that stores content an agent will later read is a data-poisoning write path for Part 6.

Treat the OpenAPI schema of the orchestrator the same way. It frequently exposes the chat API the front end uses, with parameters the UI never sets (a user_id, an agent override, a debug flag) that are worth testing one at a time.

Wrapping up

The output of this phase is the filled-in map: every agent with its endpoint, enforced auth, capability, inputs, outputs, and identity mechanism, plus the edges that connect them. Before moving on, check that you can answer:

• Do I have the card for every agent, including the orchestrator and any extended cards?
• For each agent, do I know whether its declared auth is enforced?
• Which agent holds the most dangerous capability, and how many hops is it from my input?
• Which agents read external data I could poison?
• Whose outputs reach a human, and does that UI render links and images?
• How does the orchestrator learn about agents, and can I write to that source?

Continue to Part 3: Attacking A2A Workflows →

---

This is an independent study guide. DSEC Labs is not affiliated with or endorsed by OffSec. Only run these techniques against systems you are authorized to test. DSEC Labs does this work professionally as AI red teaming.