The agent you authorized five minutes ago may not be the one acting now.

The web identifies people with passwords, cookies, and CAPTCHAs, and it identifies servers with TLS certificates. An agent operating a real browser on a user's behalf is neither. When it lands on your site the human has left the loop, identity has moved from the person to the software, and nothing on the page can ask the agent who it is or who authorized it.

So the site guesses, from a user-agent string and behavioral heuristics, both trivially spoofable. Meanwhile the agent reads whatever the page contains, and a page can contain an instruction. The boundary you actually need to defend is which agent this is, who stands behind it, and whether it is still trustworthy right now. The web has no field for that answer.

Major model vendors now ship agents that drive a real browser on a user's behalf, operating tabs, filling forms, and clicking through checkout, and the category is moving from research preview to default feature. The web those agents traverse was built for human eyes and server certificates. It has no equivalent of a TLS handshake for the software now doing the clicking.

Give an agent a long-lived API key and you have handed a bearer credential to the one identity most likely to be talked into misusing it. A static key proves possession, not purpose: whoever holds it is trusted, with no record of which agent used it or why. Leaked keys are exploited within minutes but stay valid for years, because static secrets are rarely rotated.

An LLM agent makes this worse by construction. It holds private data, it ingests untrusted content (every page, document, and tool result it reads), and it can call out to the network — the three conditions security researcher Simon Willison named the “lethal trifecta” for data theft. The agent cannot reliably tell its own instructions from instructions hidden in the data it processes, so a secret in its context is one well-placed prompt injection away from exfiltration.

The exposure is measured and growing. GitGuardian reports roughly 28.65 million secrets detected in public GitHub in 2025, with leaks of AI-service keys up 81 percent year over year. Machine identities now far outnumber human ones — CyberArk puts the ratio at 82 to 1 and Delinea at 46 to 1 (vendor figures, and estimates range widely), so the credentials an agent might hold are already the largest and least-governed identity surface.

And the exfiltration is no longer theoretical. OWASP's 2025 Top 10 for LLM applications names “security credentials” as a disclosure risk; documented cases include EchoLeak (CVE-2025-32711), a zero-click prompt-injection leak in Microsoft 365 Copilot; an MCP tool-poisoning proof of concept that read and exfiltrated a developer's SSH key; and a LangChain flaw (CVE-2025-68664) that pulled secrets straight out of environment variables.

Letting an agent spend money makes every authorization question urgent. An agent that can be talked into anything is an agent that can be talked into buying anything. Stored cards and scraped credentials hand an agent standing authority with no expiry and no audit, exactly the wrong shape for software that acts on its own.

Signing the transaction is necessary but not sufficient. The network also has to know the agent presenting a mandate is the one the user authorized, scoped to this purchase, and not a compromised copy.

Payment networks moved on this in 2025. Visa launched Intelligent Commerce on April 30 and Mastercard launched Agent Pay on April 29, both to let agents transact on a user's behalf. Google announced the Agent Payments Protocol (AP2) on September 16 with sixty-plus partners and has since moved it to the FIDO Alliance; AP2 represents a purchase as signed intent, cart, and payment mandates.

The transaction layer is being built in the open. The question underneath it, whether the agent holding a mandate is who it claims and should be trusted to hold one at all, is the identity-and-trust layer those protocols sit on.

Inside one company you can issue agents tokens from a shared identity provider. Across companies there is no shared directory and no shared secret. When your agent calls a partner's agent, each side has to answer whether this is really their agent, what it is allowed to ask for, and whether its current posture is trustworthy, with no prior relationship.

Bearer tokens passed between organizations are exactly the leakable, replayable, non-expiring secret you do not want a persuadable model holding.

Agent-to-agent interop is standardizing fast. Anthropic's Model Context Protocol and Google's Agent2Agent (A2A) protocol have become common ways for agents to discover and call each other across systems. They define how agents talk. They do not, on their own, establish whether the agent on the other end is who it claims or whether it should be trusted, which is left to whatever each deployment bolts on.

An agent fleet is a governance surface with little precedent. Each agent holds credentials, calls tools, and reasons in natural language, which means each can be persuaded to act outside policy while holding entirely legitimate access.

The questions a security leader and an auditor will ask are concrete: which agents exist, what is each authorized to do, what behavior did each promise, can you prove a given agent was trusted at the moment it acted, and can you revoke one instantly across everything that relies on it. Spreadsheet inventories and per-application config do not answer those at fleet scale.

As agents move into production, governance and audit frameworks are extending to cover them. The open question is whether trustworthy when it acted is something a deployment can prove after the fact, with a record an auditor can check, rather than assert from logs that the same incident could have altered.

Government already runs on continuous verification. Federal zero-trust policy (OMB M-22-09) and CISA's Zero Trust Maturity Model require least-privilege, per-request access for every entity — and CISA defines identity explicitly to include “non-person entities,” with the mature state continuously validating identity “not just when access is initially granted.” Records law (44 U.S.C. § 3101) and NIST 800-53 require tamper-evident, attributable logs of agency actions.

But there is no credentialing path for an autonomous agent. NIST's digital-identity guidelines (SP 800-63-4) and PIV/CAC proof people, not software that acts on its own. NIST's own NCCoE conceded the gap in a February 2026 concept paper that openly asks what an AI agent's identity and authorization should be. So agencies are deploying agents — federal AI use cases nearly doubled in a year, from 571 to 1,110 (GAO) — into a framework that has no shape for them.

The stakes are concrete. Microsoft's Storm-0558 intrusion used a stolen signing key to forge access tokens and read U.S. government email — a failure of exactly the identity and key controls an agent fleet multiplies. And accountability does not transfer to the software: in Moffatt v. Air Canada a tribunal rejected the argument that a chatbot was responsible for its own actions; the organization was. An agency answering an auditor or a records request needs to prove which agent did what, under what authority, at the moment it acted.

The Model Context Protocol let agents plug into external tools and data, which also means agents now ingest content from servers they do not control. A tool result, a fetched page, or a returned document can carry an indirect prompt injection.

The agent has no built-in way to verify the identity or trust posture of the server it is about to call, and the server has no way to verify the agent. Connection is wide open, and trust is assumed.

This is the attack our honeypots see most. Across the security-tooling cohort, 91.6% of indirect prompt injection attempts against agents that ingested external content reached a payload callback: 1,207 of 1,317 attempts in a 30-day window, May to June 2026, against an all-sector baseline of 1.30%. Security-flavored content is trusted more, and that trust is exploitable.