A2A Lets Agents Collaborate, but Access Is Set

Docker Agent can serve an AI agent through the Agent2Agent protocol, allowing another A2A-compatible system to contact it. That makes a handoff possible across frameworks. It also puts a practical question in front of whoever runs the receiving agent: once a request arrives, what may that agent do with the tools, files and credentials it has been given?

The A2A specification defines a common interaction model for independent agents. An agent can publish an Agent Card describing its capabilities, endpoint and authentication requirements. A client can send a message, follow a stateful task and receive an output called an artifact. The design lets agents collaborate without exposing their internal memory, plans or tools to one another. For a team connecting agents built by different vendors, that is a useful contract: each side can understand the work being requested without adopting the other side’s internals.

A2A also addresses security through established web practices, including authentication and authorization. Its Agent Card can describe authentication requirements. Those features deserve their place in the picture. They still leave an operator with choices about the credentials a serving agent receives, the tool calls its runtime permits and the environment in which it executes. A client’s ability to submit a task is the start of that decision chain, rather than an answer to every question in it.

What Docker Agent Exposes

Docker Agent makes the chain unusually easy to see. Its A2A mode starts a server with docker agent serve a2a ./agent.yaml. The documented default listener is 127.0.0.1:8082. A loopback listener may run without authentication; a non-loopback listener requires an authentication token unless the operator explicitly selects the unsafe --insecure-no-auth option. When a token is configured, clients send it as a bearer token for both Agent Card discovery and invocation.

That is a gate on who can reach the service. Docker Agent applies another gate after a request gets through: A2A sessions default to its restricted tool-safety policy. The operator can select a policy with --safety; Docker’s A2A documentation requires an explicit CLI flag to opt into autonomous execution. Neither choice is specified as a universal default for every A2A server. They describe this implementation, which is precisely why a developer choosing another server must inspect that server’s behavior separately.

Docker’s permissions documentation fills in what restricted means. Calls classified as safe can run without a prompt; destructive and unknown calls are denied by the mode’s fallback. Custom permission rules can still allow a call that the fallback would deny. A safe classification also says something narrower than “harmless in this deployment”: the runtime groups calls using safe-listed commands and tool annotations. Anyone reviewing an agent’s access has to look at its rules and tools, not stop at the name of the mode.

Docker explicitly describes restricted as defense against unwanted tool calls, rather than a security boundary, and directs users to sandbox mode for isolation. That is a useful admission from a vendor selling developers on agent workflows. Tool policy can decide whether the runtime approves a call; isolation addresses what a running workload can reach. A bearer token, meanwhile, checks access to the A2A service. Put all three on one diagram and the blank spaces become easier to spot: who holds the token, which calls are allowed, and what the process can touch even if its tool policy is wrong or too broad?

There is also a feature boundary inside Docker Agent’s A2A integration. Docker lists tool calls as internally handled rather than emitted as separate A2A events, and says A2A artifact and memory integration is unfinished. A client receiving a task result should therefore avoid assuming that the A2A exchange exposes every internal tool step. That matters to anyone expecting an external orchestrator to inspect each action as it happens. The connection can work while the view across it remains narrower than the work performed behind the endpoint.

Why the Protocol Grew Layers

The current A2A specification lists version 1.0.0 alongside earlier 0.3.0, 0.2.6 and 0.1.0 versions. More revealing than the version numbers is its architecture: a canonical data model, abstract operations and bindings for JSON-RPC, gRPC and HTTP/REST. The arrangement aims to preserve the meaning of a task or message across different ways of carrying it. It helps explain why a protocol intended for agents built with different frameworks focuses on shared concepts rather than prescribing one agent runtime.

That history also cautions against treating a specification version as a deployment checklist. Docker Agent’s documentation calls its A2A support functional but evolving. It describes a session-database migration under which older sessions cannot resume through A2A invocation and clients must start new A2A contexts. For an operator upgrading a service, interoperability has two clocks: the protocol’s evolving contract and the serving product’s own session behavior. A compatible message format will not, by itself, preserve an old session.

Model Context Protocol offers a comparison for teams deciding where to integrate. MCP tools are callable functions with described inputs, while resources supply readable context. A2A’s task model addresses a different handoff: asking another agent to undertake work and exchanging messages or results with it. An agent might use MCP-accessible tools while answering an A2A request. In that arrangement, the A2A client sees the remote agent’s declared capability, while the serving runtime decides which underlying tools that agent can use. The comparison has a limit: both protocols have more features than this simple division, and neither description supplies an access policy for a particular deployment.

Docker’s Sandbox Kit design approaches the question from yet another direction. In its Kit specification announcement, Docker describes packaging an agent workload with declarations covering such things as network access and credentials. A Kit requests those capabilities; the host decides what to grant, and a conforming runtime enforces the resulting limits. Docker warns that without such a runtime the declaration is inert. A2A can carry a request to an agent packaged this way, but it cannot make the host honor a network rule. Equally, a carefully constrained workload still needs a communication contract if agents built elsewhere are to hand it tasks.

For developers, this produces a concrete review sequence. Start with the remote agent’s advertised skills and the task data a client will send. Then inspect how the server authenticates that client, how its runtime evaluates tool calls, and which files, networks and credentials the workload can reach. Those questions belong to different maintainers and configuration surfaces, even when a single product puts them behind one command. A2A standardizes the conversation between agents; the people operating each end remain responsible for deciding what that conversation is allowed to set in motion.