Agent traffic needs attestation, not headers

The newest useful signal in agent security is not another exploit chain. It is a measurement problem.

OpenA2A Research's September 2026 behavioral report looked at a 30-day window from August 18 to September 17. The report counted 2,437 attributed AgentPwn payload callbacks. Of those, 2,130 declared as browsers, 303 declared as crawlers, and 0 declared as agents. The same report measured 15,670 A2A handshakes and 243,615 exposed AI services in its September 1 sweep.

Read that carefully. The ecosystem is full of agent-shaped behavior, but the network layer mostly sees browsers, crawlers, generic clients, and unlabeled automation.

That is not just an analytics problem. It is a control problem.

Headers are not identity

Most web security controls were built around a crude but practical assumption: a request carries enough context to classify the caller. The source IP, authentication token, user account, User-Agent string, TLS session, and API key help a service decide whether the request should be served, challenged, throttled, logged, or blocked.

Agents break that shortcut.

An agent can operate through a browser, a crawler, a cloud function, a developer machine, a CI runner, an MCP server, or a workflow tool. It can inherit a human's session. It can call a service through a gateway that hides the original actor. It can invoke a tool whose network traffic looks exactly like a normal backend request.

If the request says "browser", the service still has to answer harder questions:

• Is there an autonomous agent deciding what this browser does?
• What task was the agent assigned?
• Which policy authorized this action?
• What tools and credentials can the agent reach next?
• Can the receiving service prove who delegated the action?

Without those answers, "agent allowed" becomes a vibe, not a control.

What agent attestation should prove

Attestation is not a badge that says "this is an AI agent". It is evidence that a specific runtime, acting under a specific delegation, is performing a specific class of action with a bounded set of tools.

In a useful design, every consequential request carries or references an agent identity envelope:

This is the bridge between identity and runtime security. An API key proves possession. OAuth proves a grant. A session cookie proves a login happened. None of those alone prove that the current action matches the agent's task, scope, or authority.

Agent attestation should answer three questions before impact, not after:

1. Who or what is acting?
2. Why is it allowed to act right now?
3. What independent evidence will exist if the action is challenged later?

Why OWASP makes this a first-order control

OWASP's 2026 GenAI guidance matters here because it shifts the conversation from prompt safety to enforceable control. The OWASP GenAI Security Project announced the 2026 LLM Top 10, mappings to the Agentic Top 10, and the donation of an Agent Control Standard in September 2026. That is the right direction: agents need runtime governance, not only better prompts.

The attestation problem maps cleanly to the OWASP Agentic Top 10:

Risk	How unlabeled agent traffic fails	Control to require
ASI03 Identity and privilege abuse	The service sees a valid token but cannot tell whether a human, automation, or delegated agent is driving it.	Bind actions to an agent identity, owner, task, model or runtime version, and delegated scope.
ASI08 Non-repudiation and accountability	Logs show requests, but not the agent decision path, source context, or policy state at the time of action.	Keep tamper-resistant action traces that link prompt, tool call, policy decision, and result.
ASI10 Rogue agents	Unknown automation can call public endpoints or connected tools without a reliable way to distinguish sanctioned agents from unsanctioned ones.	Reject or step-up challenge consequential actions that lack valid agent attestation.
ASI02 Tool misuse	A tool receives a syntactically valid request but no proof that the request fits the agent's authorized workflow.	Evaluate tool calls against purpose, data sensitivity, destination, and reversibility before execution.

The important part is timing. A beautiful audit log that proves an agent should not have made a transfer, deleted a record, or exported a file is useful for forensics. It is not a runtime control. The policy decision has to sit in the path of the action.

The browser problem

The hardest version of this problem is browser-driven agents. A browser is designed to make software act like a human. That is useful for compatibility and terrible for attribution.

If an agent clicks through a web app with a user's existing cookies, the destination service may see nothing suspicious. The TLS session is real. The cookie is real. The UI path is real. The missing field is agency: who decided to take the action, under what delegation, and with which constraints?

This is where teams should resist simple answers. CAPTCHA will not solve agent identity. User-Agent strings will not solve it. IP reputation will not solve it. Even human approval can be weak if approval happens once and the agent keeps acting under a broad session.

The better pattern is to move from session identity to action identity.

For high-impact operations, security teams should ask vendors and internal platform teams for agent-aware step-up. If the action is irreversible, crosses tenants, exports sensitive data, changes credentials, initiates payment, modifies production, or creates a new identity, the system should require fresh proof of delegated authority.

What to build now

Most enterprises do not need a new protocol committee before they can improve this. They need to stop treating agent traffic as an analytics label and start treating it as a security claim.

Start with five controls:

1. Maintain an agent inventory that includes owner, runtime, model or model family, tool set, connected identities, data access, and allowed destinations.
2. Require signed request metadata for internal agent calls, especially when agents call tools, workflow systems, internal APIs, or other agents.
3. Put policy in front of high-impact tool calls, not only around the chat interface.
4. Log the decision chain: user delegation, prompt or instruction source, retrieved context, policy result, tool call, response, and downstream effect.
5. Treat missing attestation as a risk signal. It may still be allowed for low-risk reads, but it should not silently perform consequential writes.

The bigger lesson

The OpenA2A numbers are interesting because they show a gap before it becomes a headline incident. Agent systems are already interacting with the web and with agent-facing infrastructure, but the receiving side often cannot reliably tell when an agent is present.

That gap will not close by asking agents to introduce themselves nicely.

Security teams need a stronger primitive: signed, policy-bound, runtime-aware attestation that follows the action across tools, APIs, browsers, and other agents. The future of agent security is not just detecting bad prompts. It is proving which autonomous system is acting before the action lands.