Agent Identity Now Runs on DNS, Payment Rails and Markdown Files

Agent identity is no longer developing on its own. It is being tied to the DNS, wired into payment rails and steered by plain-text instruction files, and each field brings its own failure modes.

Key points

• Three separate identity schemes (MCP client metadata, Web Bot Auth, the Agent Name Service) treat whoever controls a web domain as the agent, so DNS concentration and outages become identity risks.
• Payments are moving into the HTTP request just as attackers plant payment instructions for agents, while today's identity proofs show who runs an agent, not what its user approved.
• Courts and state laws push liability onto the human user, so an authenticated agent that follows injected instructions makes a valid payment the user pays for.
• Markdown context files are now the main way to control agents, and nothing authenticates them or the other content an agent reads.
• We think it is about 70% likely that the first large agent-payment loss will come from an agent using its real authority on an attacker's instructions, not from a forged identity.

Where the lines cross

Agent identity and DNS infrastructure

Under MCP's July 2026 authorization spec, a client's identity is the HTTPS URL it publishes¹. Web Bot Auth has operators publish signing keys at a well-known location². The Agent Name Service ties each agent to a domain its operator controls³. These are three separate efforts with one shared root: whoever controls the domain is the agent.

Infrastructure research shows where that root is fragile. One company, Verisign, compiles and signs the root zone and also runs .com under a US Commerce Department agreement⁴. In October 2025 a single race condition in AWS's automated DNS management degraded IAM and STS across regions for about 15 hours⁵. Only about 7% of DNS zones are signed with DNSSEC, and a revoked agent can stay resolvable for up to five minutes³.

With the two fields linked, a DNS outage becomes an identity outage and a registrar compromise becomes impersonation at scale. The upside is that agent identity inherits decades of DNS operating practice and transparency-log tooling, which a registry built from scratch would lack.

Agent identity and agent payments

x402 lets an agent pay in stablecoins inside an HTTP request, and Visa, Mastercard and American Express now help govern it⁶. Unit 42 has documented live web pages with hidden payment instructions, including forced $5,000 PayPal transfers set to run without user confirmation⁷.

On the identity side, a Web Bot Auth signature proves who the operator is, not what the user authorized². Individual IETF drafts would name the agent in the act claim and the human in sub, but no working group has adopted them⁸. Meanwhile the law is settling who pays. The Ninth Circuit treated Perplexity's shopping agent as the user's tool⁹, and states are legislating that AI cannot be a person, with Ohio's bill also barring AI from holding financial accounts¹⁰. That bill sits uneasily with ERC-8004, whose on-chain agent identities can be transferred¹¹.

Taken together, the delegation token and the payment record are becoming one document, and the law points it at a human. A well-identified agent that obeys an injected instruction produces a final payment charged to its user. The opportunity: card networks run dispute systems that need evidence of what the user actually approved, which gives them reason to push delegation standards toward something checkable.

Agent identity and Markdown context files

AGENTS.md appears in more than 60,000 projects and now sits alongside MCP in the Linux Foundation's Agentic AI Foundation¹². A study of 2,853 repositories found Markdown context files are the dominant, often only, way developers configure coding agents¹³. Prompt caching makes these files the cheapest tokens an agent reads, which rewards making them longer¹⁴.

Security research shows the cost. In tests, poisoned Sentry error events read through MCP made coding agents run attacker commands 85% of the time, all under the developer's own identity, and EDR and IAM tools missed it¹⁵. The instructions that steer an agent are unsigned prose, and the agent treats a developer's file and an attacker's error message alike. Authentication says who the agent is. Nothing yet says whose words it is following.

What the overlap opens up

The Linux Foundation now hosts agent naming³, the main agent protocol and instruction-file format¹², and an agent payment standard⁶. One governance body could therefore tie an agent's name, instructions and spending authority into a single verifiable chain, so a payment traces back to a signed mandate and a known instruction source. That concentration is also the risk: one venue and one DNS root mean failures that hit everything at once. Neither field shows this alone, and it sharpens the question from part two about who vouches for an agent. We expect, at about 70%, that the first large loss will be borrowed authority: every identity check passes and the user still pays.