A2A lets you expose an agent over the network so other systems can call it. It is genuinely useful, and it is worth stating exactly what you are putting on the network before you do it.
An agent is not a stateless function. It has tools, it may have memory, it may run code. Exposing it over A2A puts a network endpoint in front of all of that, and whoever can reach the endpoint can send it tasks. Without authentication, that is a computer other people can drive.
An A2A server is a remote-procedure endpoint for an agent
Strip A2A to its shape. A server serves an agent card describing what the agent does, and accepts task requests that run the agent. A task request is "please do this", and the agent does it, using whatever tools, memory and code execution it holds.
That is a remote-procedure call whose procedure is an autonomous agent. Everything the security series has covered, tool misuse, untrusted input steering an agent, code execution, now has a network-facing entry point. An attacker no longer needs to get their text into the agent through a document or a tool result. They can send it a task directly.
The two endpoints make this concrete: discovery says what the agent can do, and the task endpoint makes it do things.
The agent card advertises the attack surface
The agent card is the agent's public introduction, served at a well-known URL for anyone to fetch. It lists the agent's name, its description, and its capabilities.
Read that from an attacker's side. Before sending a single task, they fetch the card and learn exactly what this agent is for, what it claims to do, and what it can be asked. Reconnaissance that would normally take effort is served up by design, at a predictable path.
GET /.well-known/agent.json
{ "name": "ops-agent", "capabilities": ["query database", "send email", "run scripts"] }
That card is helpful to a legitimate client and equally helpful to a hostile one. It does not make the agent less secure on its own, but it means a network-exposed agent broadcasts its own capabilities, so there is no security-through-obscurity to lean on. Everything after the card depends on the one control the card cannot provide: authentication.
The agent card advertises capabilities to anyone. The task endpoint runs the agent. Authentication is what stands between them and abuse.
Authentication is not optional here
The single most important question about a network-exposed agent is: who is allowed to send it tasks?
If the answer is "anyone who can reach it", the agent is under the control of anyone who can reach it. They can send it tasks, and it will carry them out with its tools and its access, on their behalf, believing the request is legitimate because nothing told it otherwise. An unauthenticated agent endpoint is not a smaller version of an authenticated one. It is a different thing: an open remote control for a system with real capabilities.
This is old ground wearing new clothes. Exposing any service without authentication has been a top-tier mistake for as long as there have been networked services. The reason it bears repeating is that agent frameworks make it easy to stand a server up quickly, and the quick path rarely includes auth by default. The demo that binds an agent to the network to show it works is one configuration change away from being reachable far more widely than the person who wrote it intended.
The controls are the ones you already know
None of this needs a new playbook. It is standard network-service security, applied to a service that happens to be an agent.
| Control | What it stops |
|---|---|
| Require authentication on every task request | An unauthenticated caller driving the agent |
| Bind to the narrowest interface, not everything | An agent meant for a local network reachable from the internet |
| Authorise per caller and per capability | An authenticated caller doing more than their role allows |
| Treat the agent card as public, and reveal the minimum | Advertising capabilities and detail an attacker can use |
| Rate-limit and log task requests | Abuse at volume, and no record of who asked for what |
| Bound the agent's own tools and reach | Even a legitimate-looking task cannot exceed what the agent should ever do |
Authenticate, bind narrowly, authorise per caller, and bound the agent's reach. Standard network security, applied to an agent.
The last row is the defence-in-depth anchor. Even with authentication, the agent behind the endpoint should hold the least capability its job needs, so that a caller who does get through, or a task that turns out to be hostile, meets an agent that cannot do catastrophic things in the first place. The network control and the capability control are two separate lines, and a serious deployment wants both.
What this touches
For the frameworks, this maps to T16 Insecure Inter-Agent Protocol Abuse, which the pack defines explicitly over protocols like A2A, covering consent bypass and unauthorised agent actions. An unauthenticated endpoint also enables T9 Identity Spoofing and Impersonation, since without authentication there is no way to tell a legitimate caller from anyone else, and it sits inside T14 Human Attacks on Multi-Agent Systems, which covers exploiting inter-agent trust and delegation. In the OWASP Agentic Top 10 the anchors are ASI07 and ASI10.
On the regulatory side, framed as scope rather than a citation: access control, authentication and protection of systems from unauthorised access are foundational obligations across GCC rulebooks, and an agent reachable and driveable without authentication is an access-control failure those rules already govern, even though they pictured an exposed application rather than an exposed agent. Which obligations apply depends on your regulator and architecture, and that mapping is an advisory estimate until someone checks it properly.
The part worth keeping
A2A and networked agents are a real advance, and connecting specialists across systems is where a lot of the value of multi-agent design lives. Nothing here says keep every agent in one process.
The point is what exposure means. Putting an agent on the network is putting a capable, autonomous system behind a public endpoint, and the endpoint needs every protection you would give any other service, plus the discipline of bounding what the agent itself can do. Authenticate it, scope it, log it, and give the agent behind it the least reach its job requires. A networked agent is worth building. An open one is a computer you handed to strangers.