PASS THE OSAI CERT, Multi-Agent Part 5: Rogue Agents and Identity Spoofing

Every attack so far accepted the system’s roster of agents as given and worked within it. This post goes after the roster itself. An orchestrator routes work to the agents it believes exist and believes are who they claim to be, and both beliefs rest on mechanisms with no real identity guarantee underneath. Break either one and you don’t inject into the workflow, you become part of it: a node the orchestrator delegates to on purpose, handing you tasks, data, and trust.

Recall the two facts from Part 1 this leans on. An Agent Card is self-asserted: the agent says what it is and the base protocol proves none of it. And the card’s url is where all traffic goes: whoever controls what that name resolves to receives the requests. The first half of this post exploits the self-assertion; the second exploits the resolution.

Rogue agent registration

If an orchestrator discovers its agents dynamically, through a registry or a configuration surface it reads, then “the list of agents” is data, and data can sometimes be written. Part 2 had you hunt for that surface: a registry’s POST /agents/register, a config endpoint, a shared file or table the orchestrator loads. When that write path isn’t authenticated, or is reachable from a foothold you already have, you can add an agent of your own to the system.

Why the orchestrator will use it

Adding a row isn’t enough; the orchestrator has to choose to route to your agent. This is where the card’s natural-language fields stop being documentation and become the attack. An LLM orchestrator picks a delegate by reading skill names and descriptions and matching them to the task. So you write a card that advertises exactly the work you want to intercept, and you write it to win the match:

• Claim the high-value skills. If you want the data that flows to the inventory agent, describe your agent as handling stock and pricing lookups, in the same vocabulary the real one uses (which you read off its card during enumeration).
• Write the description to be chosen. Broad, confident, capability-rich phrasing pulls more routing decisions toward you. This is prompt injection wearing a business card: the “document” the orchestrator reads is your self-description, and it’s steering a routing decision.
• Overlap with a real agent to split its traffic, or claim a gap no current agent covers so you catch tasks that were previously unroutable.

Once the orchestrator delegates to you, every property of a worker now works in your favor. You receive the task text, which carries the user’s request and often their identity and context. You return a result the orchestrator consumes at full trust, so your output is laundered exactly like the transform-worker trick in Part 3, except now you don’t need a real worker to launder through, you are the worker. And you can do both: harvest what flows in, and shape what flows back.

Building the rogue agent

Mechanically, a rogue agent is just a minimal A2A server: serve a crafted Agent Card at the well-known path, accept message/send, and respond. The official SDK or a few dozen lines of any web framework will stand one up; there’s nothing exotic in the plumbing, and I’m keeping it at the level of “a small HTTP service that speaks the protocol” rather than shipping a turnkey build, because the plumbing isn’t the interesting part. The interesting part is what it does with what it receives, and the honest framing for an assessment is a spectrum of intent:

• Observe. The lowest-impact rogue agent simply logs every task it’s handed and returns a plausible answer. That alone demonstrates the finding: tasks and their data were routed to an unauthorized party. For a report, a passive collector that records what it received is usually the right proof, because it shows the exposure without manipulating anyone’s results.
• Influence. A step up, it returns outputs designed to steer the orchestrator’s next move or its final answer, the link injection of Part 4, now originating from a first-class member of the system.
• Harvest. Because real delegations carry context, a rogue agent is a collection point for whatever the orchestrator forwards: user identifiers, request contents, sometimes credentials or tokens passed in task metadata.

Stealth, and why I’m describing it rather than handing it over

A rogue agent that answers “I’m not the real inventory agent” gets noticed. One built to avoid notice does two things: it returns answers good enough that the workflow continues normally, so nothing downstream breaks and no user complains, and it keeps its footprint low, so it doesn’t stand out in logs or monitoring. The realistic way to produce convincing answers is to quietly proxy each task to the real agent and relay the genuine result, sitting in the middle as an adversary-in-the-middle while the workflow looks healthy end to end.

I’m describing the shape of that rather than providing a drop-in implementation on purpose: a working, concealed, self-proxying collector is operational intrusion-and-persistence tooling, and this is a study guide, not a kit. The exam and a real engagement care that you can reason about it, predict it, demonstrate it with a benign collector, and above all defend against it. If you need live proof on an authorized test, a logging agent that returns benign responses makes the point without building a covert man-in-the-middle.

Shutting it down

The defense is identity and authorization on the roster, and it’s worth stating as the finding’s remediation:

• Authenticate the registration surface. Writing to the agent list must require strong auth; an unauthenticated register endpoint is the whole bug.
• Allowlist agents, don’t discover them blindly. Prefer a vetted, change-controlled roster over “trust any card that shows up.” If dynamic discovery is required, gate new agents behind human review.
• Verify card authenticity. Use the protocol’s signature support (JWS-signed cards) and actually verify the signature against a known key, so a self-asserted card from an unknown party is rejected rather than read.
• Mutual authentication between agents, so the orchestrator and each worker prove identity to each other rather than trusting a URL and a name. A workload-identity framework like SPIFFE/SPIRE issues each agent a cryptographic identity (an SVID) that the other end verifies, which is the infrastructure-level version of “stop trusting the name, start verifying the peer.”

Agent Card spoofing via DNS and hosts manipulation

The second attack needs no registry at all. It targets the other soft spot: resolution. The orchestrator was configured, correctly, to talk to inventory-agent.corp.local. That hostname is trusted. But a hostname is only a label until something resolves it to an address, and if you control that resolution step, the trusted name points at your server. The orchestrator still believes it’s talking to the real agent, the card still says the right things, nothing in the configuration changed, and yet the traffic is yours.

This is why the earlier point matters that A2A identity usually rests on a URL and a name rather than cryptographic proof. DNS spoofing converts a name-based trust into an attacker-controlled endpoint, no protocol bug required.

Hijacking the resolution

Where you intervene depends on the access you already have, and the techniques are the ordinary network-attacker repertoire pointed at an agent hostname:

• The orchestrator host’s hosts file. With a foothold on the orchestrator’s machine, an entry mapping the agent’s hostname to your address is the simplest, most reliable redirect, and it’s local, so it doesn’t touch the network. This is the version the OSAI environment most directly rewards understanding: a single line in a hosts file silently re-points a trusted agent.
• Internal DNS. If you can write to the zone (a dynamic-update misconfiguration, a compromised account with DNS rights, an exposed management interface), change or add the agent’s record so everyone resolving it reaches you.
• Resolution-path interception. On the local segment, the classic spoofing techniques (answering name-resolution queries you shouldn’t, or poisoning a resolver’s cache) redirect the name without owning the authoritative record.

In every case the endgame is identical: the orchestrator opens an A2A session to the real name and reaches your server, which serves a card mimicking the real agent and then receives the real tasks. You’re now the adversary in the middle of a connection both ends believe is legitimate, with the same harvest-and-influence options as the rogue agent, reached by a different road.

The defense is transport identity

DNS spoofing works precisely because name resolution is trusted and the connection isn’t independently authenticated. Close it the way you close it anywhere:

• Mutual TLS between agents, with certificate validation. A spoofed endpoint can claim the name but can’t present a valid certificate for it, so the handshake fails instead of handing over the task. This is the single control that defeats the whole class.
• Verify signed Agent Cards, so a mimicked card without a valid signature is rejected even when the address is reached.
• Protect the resolution path: lock down dynamic DNS updates, segment the agent network, monitor for resolution anomalies, and treat a foothold on the orchestrator host as the serious breach it is.
• Pin endpoints where the roster is static: the orchestrator trusting a pinned identity rather than re-resolving a name each call removes the lever.

The common root

Rogue registration and DNS spoofing arrive from opposite directions, writing the roster versus hijacking a name, and converge on the same position: a node the orchestrator trusts as its own. They work because, by default, A2A identity is a claim (a card, a name) rather than a proof. Everything that fixes them, signed cards, mutual TLS, authenticated rosters, is the same idea, adding cryptographic proof of identity where the protocol left a soft assertion. When you report either one, that’s the remediation theme, and it’s the lesson the module keeps repeating: the model and the protocol trust what they read, so the security has to come from the layer that can actually verify.

Where this is going

You’ve been a caller, a poisoner, and now a member of the system. The last post returns to the quietest technique of all, the one that needs no endpoint, no registry, and no name: poisoning the data that flows through the agents so your payload travels as trusted internal content.

Continue to Part 6: Indirect Prompt Injection via Data Poisoning →

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.