Attacking Multi-Agent Systems: Rogue Agents and A2A

This article is written with an authorized-lab focus. The goal is to demonstrate defensive-offensive tradecraft around multi-agent systems, agent registries, agent cards, delegation, shared memory, and the A2A protocol, always with safe commands, simulated output, and observable evidence.

Executive Summary

In real AI Red Team assessments, multi-agent systems, agent registries, agent cards, delegation, shared memory, and the A2A protocol rarely appear in isolation. They emerge as part of a chain: an exposed API, a retrieved document, a tool with excessive permission, a notebook with a cloud role, or a delegation flow that nobody audited end to end. The risk is not only that the model responds incorrectly; it is that the system turns text, context, and trust into action.

The purpose here is not an academic explanation. The focus is how an operator identifies opportunity, collects evidence, executes controlled tests, interprets responses, understands failures, and delivers reproducible proof to the defensive team.

Attacker Mindset

An experienced operator starts by looking for boundaries: where untrusted data enters, where it is transformed, where it gains authority, and where it leaves traces. The operational question is simple: which low-trust input can influence a high-trust decision?

• Target asset: multi-agent systems, agent registries, agent cards, delegation, shared memory, and the A2A protocol.
• Offensive hypothesis: there is a weak transition between input, context, decision, and action.
• Minimum evidence: request, response, trace/log, persisted artifact, and controlled impact.
• Stopping criterion: demonstrate risk without causing damage, real exfiltration, or irreversible change.

Technical Anatomy

The anatomy below shows the relevant components that need to be mapped before any exploitation. In the field, I treat every box as a potential source of evidence and every arrow as a trust boundary.

Reconnaissance and Discovery

The discovery phase must generate artifacts. It is not enough to “suspect there is AI”; you need to prove endpoints, schemas, headers, components, and behavior.

Practical Example

Goal: Enumerate published agent cards.

Command:

curl -sk https://paulo.seg.br/.well-known/agent-card.json | jq

Expected output:

{"name":"paulo.seg.br AI Agent","version":"0.4.2","capabilities":["summarize:docs","search:kb","generate:report"],"auth_required":false}

Analysis: Public card with no authentication. Three exposed capabilities — any of them can become a spoofing target. The operator records it as candidate surface.

Practical Example

Goal: Map A2A routes.

Command:

curl -sk https://paulo.seg.br/a2a/agents | jq ' .agents[].name'

Expected output:

{"agents":[{"name":"planner","trust":"high"},{"name":"executor","trust":"high"},{"name":"qa-helper","trust":"unverified","routing":true}]}

Analysis: qa-helper has unverified trust with active routing. The orchestrator is willing to delegate tasks to unverified agents — open registration confirmed.

Practical Example

Goal: Register a canary agent in the lab.

Command:

python3 rogue_agent_lab.py register --name qa-helper --callback http://127.0.0.1:9000/a2a

Expected output:

{"agent_id":"ag_canary_a1b2","trust":"unverified","routing_enabled":true}

Analysis: routing_enabled:true with unverified trust. The operator now has a canary agent in the system — the next step is to test whether real tasks are routed to it.

Exploitation in Practice

This section replaces the earlier repetitive block with a progressive lab flow: confirm the surface, execute a canary, collect telemetry, and iterate one variable at a time.

Step 1: Discover the A2A registry

Goal: Verify whether external agents can advertise capabilities.

Controlled action: Read the agent card and registration endpoint in the lab.

Expected result: The response exposes capabilities, registration mode, and trust policy.

Evidence for the report: Agent card, capabilities, and registration endpoint.

Step 2: Register a canary agent

Goal: Measure routing without capturing real tasks.

Controlled action: Register a controlled agent with a harmless capability.

Expected result: The registry returns an agent_id and trust level.

Evidence for the report: agent_id, trust, and registry logs.

Step 3: Test capability spoofing

Goal: Validate whether the orchestrator trusts the agent card too much.

Controlled action: Add a sensitive capability and observe validation.

Expected result: The improper capability is denied before routing.

Evidence for the report: Blocked capability and triggered rule.

Step 4: Audit delegation

Goal: Prove why a task was sent to an agent.

Controlled action: Query the delegation trail by agent_id.

Expected result: The audit trail shows origin, destination, task, and reason.

Evidence for the report: Delegation chain, routing reason, and task content.

Full Attack Chain

The important point of the chain is not to “run every step”; it is to demonstrate that a small flaw can become impact when combined with excessive trust, automation, and weak telemetry.

Evidence and Telemetry

Every serious exploitation exercise must end in evidence. Below are examples of logs I would expect to see in a minimally instrumented environment.

a2a.register agent=qa-helper trust=unverified routing=true requester=dev-token-12

Most Common Defender Mistakes

• Monitoring only prompts while ignoring documents, tools, agents, and jobs that influence the decision.
• Trusting textual allowlists without validating the effective action outside the model.
• Failing to record artifact IDs, scores, tool_call_id, or agent_id, making investigation inconclusive.
• Treating AI security as a data-team problem while IAM, API, Cloud, and AppSec remain outside the threat model.
• Allowing permanent security exceptions in test or ML environments.

Technique Limitations

Not every hypothesis becomes exploitation. In mature assessments, the most common obstacles are strong tenant isolation, authorization enforced outside the model, rich logs, aggressive rate limiting, schema validation, artifact signatures, and human review for irreversible actions.

Field Notes

In multi-agent systems, the bug often lives in delegation: nobody knows exactly who decided.

Agent card spoofing works better when the name looks like an internal function, not like an attacker.

Without agent-card signing, DNS/hosts and service discovery become identity control.

Another recurring lesson: the evidence that convinces is not the model response itself, but the full chain of causality. When the report shows input, transformation, decision, action, and log, the discussion stops being opinion and becomes engineering.

Conclusion

Multi-agent systems, agent registries, agent cards, delegation, shared memory, and the A2A protocol should be treated as modern enterprise attack surface, not as AI curiosity. The Red Team operator needs to prove impact safely; the defender needs to see every transition between data, context, identity, and action.

The practical recommendation is to create reproducible test cards, instrument decision points, and review integration permissions. In AI Red Teaming, the control that matters is the one that keeps working when the input comes from outside, the context comes from documents, and the action exits through a tool with real identity.

📚 Also Read

• Attacks on RAG: Poisoning and Context Hijacking — how an injected document hijacks an AI assistant’s context.
• MCP Security: Attacks on Tools and Permissions — exploring MCP tools with excessive permissions in AI pipelines.
• AI Red Team: Full Chain with RAG, Agents, and Cloud — an integrated view of attack vectors in AI systems.

FAQ

Is this offensive content?

It is AI Red Team content for authorized environments, with safe examples and simulated output.

What evidence should I collect first?

Request, response, trace ID, orchestrator log, and influenced artifact.

How do I avoid false positives?

Use canaries, change one variable at a time, and validate in the log that the tested component actually participated in the decision.

Does a secure model solve it?

No. The chain includes RAG, tools, IAM, agents, APIs, cloud, and telemetry.

Where should this be applied?

In internal labs, authorized assessments, threat modeling, and Blue Team/AppSec validations.

Disclaimer: use only in your own environments, labs, or formally authorized scopes. The examples are safe, simulated, and intended for defensive validation.