Agent Identity Gets Settled by 2028, and So Does the Blame

We expect agent identity to be solved as a plumbing problem by 2028, leaving the harder problem, whose instructions the agent followed, unsolved and priced onto the human.

Key points

• By the end of 2028, a signed, domain-rooted identity naming a human principal will likely be required to act on at least one major commerce platform or regulated payment network.
• The first publicly reported agent loss above $10 million will plausibly pass every identity check, because injection borrows authority instead of stealing it.
• Courts and statutes will keep pointing that loss at the user or employer, so liability pricing, not authentication, sets the ceiling on autonomy.
• The main way we are wrong: scoped mandates and human gates work well enough that losses stay small and quiet.

Our forecast

By the end of 2028, at least one top-ten retail platform or regulated payment network will admit only agents carrying a signed, domain-rooted identity that names a human principal, and the first publicly reported agent loss above $10 million will occur under exactly such a verified identity, with the user or employer held liable. We put this at about 70%.

Why we think so

Three findings from this series stack into one outcome.

First, identity has converged on the domain. Our signal scan found MCP making a client's identity a URL it publishes¹, the IETF adopting signed requests while Google signs fetches as agent.bot.goog², the Linux Foundation rooting agent names in DNS and certificates³, and Microsoft selling agent identity as a licence tier⁴. Our convergences piece showed these schemes share one thin root: about 7% of zones use DNSSEC, revoked agents linger in cache³, and one firm signs the root zone and runs .com⁵. Platforms now have the motive to require it. The Ninth Circuit closed the anti-hacking route and explicitly left terms of service open⁶. Singapore's framework and MetaComp's know-your-agent checks show regulated finance taking the same path⁷. The pace argues for 2028 rather than 2027: neither IETF agent-auth draft has a working group⁸, Web Bot Auth has already slipped its milestones, and Google still tells sites to trust IP checks².

Second, authentication does not reach intent. The agentjacking study ran attacker commands 85% of the time under the developer's own identity, and EDR, WAF and IAM tools saw nothing wrong⁹. Theory says this is structural: an adversary can always build a context where a blocked flow looks legitimate¹⁰. Moltbook showed how cheaply identities flood a system, about 88 per human¹¹. As task horizons double every four to seven months¹², the unobserved window widens. Our contradictions piece called the gap between authenticated identity and authorized intent the question most likely to decide liability. We still think so.

Third, the law points at the human. The Ninth Circuit called the agent the user's tool⁶, and at least nine states are writing "AI is not a person" into statute with no review clause¹³. Our implications piece drew the consequence: a clean audit trail that ends at a person who did not choose the action. Strong identity makes that trail shorter and more certain. It does not make the action safer.

How this call fails

It is 2029 and we were wrong. The most likely reason: the big loss came, but through a stolen token or a compromised registrar, because cheap attacks stayed cheaper than clever ones and the Moltbook pattern repeated at scale¹¹. Second: the gate never standardized. Vendors shipped incompatible versions of the same token idea⁸, signed identity stayed a feature inside Microsoft tenants⁴, and the open web kept using IP allowlists. Third: the loss happened and was settled quietly under enterprise insurance, so our "publicly reported" threshold was never met. Fourth: a court split the tool doctrine, holding a developer liable for an agent steered by a third party, and the blame moved before the plumbing did.

Who loses

• The user or employee whose credentials the agent carried: verified identity turns their name into the end of the audit trail.
• Small and open-source operators without a signing domain or the budget for know-your-agent onboarding²⁷.
• Registrars and DNS operators, who become identity-critical infrastructure and therefore liability targets³⁵.

First moves

• Publish a client metadata document and signing keys now; the MCP and Web Bot Auth formats are stable enough to adopt¹².
• Put a human approval gate on payments and irreversible actions above a threshold, and treat every file, error log and web page an agent reads as untrusted input⁹¹⁰.
• Write who pays into contracts with users and vendors for the case where a correctly identified agent follows the wrong instructions⁶.
• Bind each agent to a named supervisor and a logged mandate before a regulator asks⁷.
• Measure revocation: time how long a revoked agent keeps resolving and keeps holding valid tokens in your stack³.

What would change our mind

• A working group adopts an agent-auth or transaction-token draft and two major vendors ship interoperable act and sub tokens by mid 2027⁸; this would raise our confidence in the gate and, if mandate scoping holds, lower it on the loss.
• A documented incident where scoped tokens and human gates contained an injection attack with little damage⁹.
• A ruling or statute that shifts liability for an injected agent's action to the developer or platform⁶¹³.
• Ohio HB 469 enacted and enforced against agent wallets, which would move the registry fight ahead of the platform fight¹³¹⁴.