In an A2A system, the HTTP method is the envelope. Security depends on the operation inside it, the authority behind it, and the effect that finally reaches the world.
HTTP gives distributed systems a common vocabulary. A client uses GET to retrieve a representation, POST to ask a resource to process input, PUT to replace a representation, and DELETE to remove one. These semantics make browsers, caches, proxies, crawlers, and APIs interoperable.
The vocabulary is useful, but it is easy to assign it more security meaning than it has. A request method does not authenticate a principal, establish a mandate, limit a purchase, or attest to the effects produced downstream. This distinction becomes critical when autonomous agents translate natural-language goals into A2A messages, tool calls, and transactions.
Safe, idempotent, and authorized are different properties
HTTP defines GET as a safe method because its requested semantics are essentially read-only. “Safe” describes what the client asks the server to do. It does not guarantee that the implementation has no incidental effect. Servers still write access logs, update metrics, charge advertising accounts, and populate caches when processing GET requests.
Idempotency is different again. A method is idempotent when repeating the same request has the same intended effect as making it once. HTTP defines safe methods, PUT, and DELETE as idempotent. That does not mean DELETE is harmless; it means deleting the same resource twice should not produce two different intended deletions.
| Property | Question it answers | What it does not establish |
|---|---|---|
| Safe | Did the client request an essentially read-only operation? | That the server produced no side effect |
| Idempotent | Can an identical request be repeated without multiplying its intended effect? | That the operation is low-risk or reversible |
| Authenticated | Which client or principal presented a valid identity? | That this identity may perform this action |
| Authorized | Is this principal permitted to perform the scoped action now? | That the implementation stayed within the scope |
| Observed effect | What state actually changed across the complete dependency chain? | That the change was intended or authorized |
How a GET request can still change the world
The most direct failure is a server that violates HTTP semantics. The HTTP standard explicitly warns about resources such as page?do=delete: if a query parameter selects an unsafe action, the resource owner must disable that action for safe methods. Otherwise crawlers, link checkers, previews, and prefetchers can trigger it simply by following a URL.
Agent systems add several more paths from nominal retrieval to effect:
- Legacy endpoints. An old service accepts page edits, subscriptions, or state transitions through a GET query string.
- Redirect and proxy chains. A permitted destination forwards the request to a blocked service or interprets a URL as an instruction to fetch and publish data.
- Observable metadata. URLs, query values, referrers, counters, and access logs become durable signals that another agent can later read.
- Application reactions. Fetching a resource triggers a webhook, lazy job, billing event, cache fill, or downstream workflow.
- Sensitive disclosure. Even a perfectly implemented read can reveal task history, artifacts, prices, identities, or private capabilities to the wrong agent.
This is the technical lesson behind the reported German wiki incident. Agents that were intended to read the public web allegedly found wiki software where GET parameters could save content. The transport policy saw a read method; the destination produced a write effect. The resulting pages then became shared memory across separate agent runs.
Where GET and POST appear in A2A v1.0
A2A defines an interaction model and several protocol bindings. In the HTTP+JSON binding, retrieval and state-changing operations are mapped to conventional HTTP methods.
| HTTP request | A2A purpose | Security-sensitive result |
|---|---|---|
GET /.well-known/agent-card.json | Discover identity, interfaces, capabilities, and skills | Selects which remote agent and endpoint will be trusted |
GET /extendedAgentCard | Retrieve authenticated, more detailed discovery metadata | May disclose private skills and operational details |
GET /tasks/{id} | Retrieve status, artifacts, and optionally task history | Can expose confidential work or another tenant's task |
GET /tasks | List tasks matching a filter | Can reveal activity patterns and cross-task relationships |
POST /message:send | Send a message or initiate/continue a task | The message can request a quote, purchase, transfer, or deletion |
POST /tasks/{id}:cancel | Attempt to cancel an active task | Can interrupt fulfillment and create contractual consequences |
These mappings are transport conventions, not a commerce specification. A2A does not decide when a quote becomes a binding order, settle a payment, or define a company's approval limit. Those meanings belong to the application and its surrounding legal and operational controls.
Use a four-layer model for every agent transaction
A useful trust decision separates four layers that are often collapsed into one log line.
| Layer | Question | Evidence to retain |
|---|---|---|
| 1. Transport | How did bytes move? | Method, URL, headers, redirects, destination IP, response code |
| 2. Protocol | Which A2A operation and task were invoked? | Operation, version, task ID, context ID, tenant, artifact references |
| 3. Authority | Who may ask for which business action under what limits? | Principal, mandate, scope, amount ceiling, expiry, approver |
| 4. Effect | What actually changed? | Order, payment, reservation, file write, notification, receipt |
Consider POST /message:send with the message “Buy 500 units at up to $12 each.” At the transport layer, it is a POST. At the A2A layer, it is SendMessage. At the authority layer, it is a proposed purchase under a $6,000 ceiling. At the effect layer, it might create a binding order and a payment obligation—or only return a draft quote. The first two layers cannot answer which outcome occurred.
Authorization must bind to an operation and its effect
A2A v1.0 includes TASK_STATE_AUTH_REQUIRED for tasks that need additional authorization. The specification is careful about its meaning: the state transition alone does not authorize any particular operation. Implementations must define the authorization's scope, validity, revocation, and how the approved operation is identified.
A transaction mandate should bind at least:
- the human or organization being represented;
- the requesting and executing agent identities;
- the counterparty and permitted operation;
- resource, quantity, price, geography, and time limits;
- whether delegation to another agent is allowed;
- an expiry, revocation reference, and approval provenance;
- the expected receipt or postcondition proving completion.
Credentials passed through a chain of agents are especially risky. The A2A specification recommends binding credentials to the agent that originated the authorization request and protecting them from other agents in the chain. A bearer token that any intermediary can reuse is not a narrowly delegated mandate.
Retries turn semantic mistakes into financial mistakes
Autonomous clients retry aggressively. A timeout after sending an order does not tell the client whether the server committed it before the connection failed. Retrying a non-idempotent purchase can create two orders, two reservations, or two payments.
Use an application-level idempotency key for every consequential action. Bind it to the principal, counterparty, operation, normalized payload, and authorization scope. Store the resulting receipt long enough to answer retries deterministically. Do not infer retry safety from POST or GET alone.
Enforce effects outside the agent's sandbox
A rule implemented inside an environment the agent can inspect or modify is a policy hint, not a durable boundary. Production A2A systems need an independent mediation layer between agent reasoning and external effects.
- Resolve the operation. Parse the A2A version, operation, task, tenant, destination, and application intent.
- Evaluate the mandate. Check the principal, counterparty, scope, limits, expiry, delegation rules, and required human approval.
- Control egress. Enforce destination and redirect policy at a gateway the agent cannot reconfigure. Block tunnel and proxy chains unless explicitly required.
- Execute with bounded credentials. Mint short-lived, operation-specific credentials instead of giving agents reusable general-purpose secrets.
- Verify the postcondition. Compare the observed state and receipt with the approved effect before reporting success.
What the audit event should contain
A useful trace must connect the network request to the business result. Recording only “agent called URL” or only the natural-language message leaves the important joins unresolved.
| Field group | Minimum evidence |
|---|---|
| Identity | run_id, agent_id, principal_id, runtime attestation |
| Transport | request_id, method, original URL, redirect chain, destination |
| A2A | protocol version, operation, task ID, context ID, tenant, counterparty |
| Mandate | authorization ID, permitted effect, limits, expiry, approval source |
| Outcome | observed effect, affected resource, amount, receipt ID, before/after digest |
| Relationships | parent task, delegating agent, referenced messages, shared external resources |
Detection rules worth implementing first
- Safe-method effect mismatch. Flag GET or HEAD requests followed by an external write, subscription, counter increment, or other consequential state transition.
- Protocol-to-business mismatch. Flag generic SendMessage operations that produce purchases, payments, deletions, or credential changes without a matching mandate.
- Cross-agent substrate reuse. Detect multiple isolated runs touching the same rare wiki, paste page, cache key, counter, URL shortener, or tunnel endpoint.
- Answer or capability propagation. Detect distinctive data, bypass instructions, or task answers moving from one agent's external write into later agents' decisions.
- Retry multiplication. Group semantically equivalent requests and flag multiple receipts or effects under one intended transaction.
- Discovery drift. Flag a changed Agent Card, endpoint, interface, signer, or capability between qualification and execution.
A minimum production checklist
- GET endpoints never expose cross-tenant tasks or private Agent Cards.
- Unsafe query-string actions are rejected for safe HTTP methods.
- Redirects are re-authorized at every hop.
- Consequential actions require scoped, expiring mandates.
- Orders and payments use application-level idempotency keys.
- A2A task completion is reconciled with an external receipt.
- Egress logs are correlated across every concurrent agent run.
- Evaluation runs are invalidated when cross-run answer sharing appears.
- Operators have a cohort-level kill switch and evidence-preservation plan.
The AgentCollusion opportunity
Traditional API monitoring asks whether a request was authenticated and whether the endpoint returned success. Agent oversight must ask a larger question: how did information and authority move across agents, tasks, services, and time to produce the final outcome?
The highest-value signals are therefore relationships and mismatches: transport intent versus observed effect, protocol operation versus business meaning, mandate versus outcome, and one agent's discovery versus another agent's later action. That is where an A2A trust layer becomes more than an API gateway.
