Permission Manifests: robots.txt Was Never Built for Agents That Act
robots.txt has answered exactly one question since 1994: where should a crawler not look. That question made sense when the only thing hitting your site with a bot in the user-agent string was going to read a page and leave. It stopped making sense the moment agents started filling out forms, completing checkouts, and taking multi-step actions on a user's behalf — because "don't read this page" has no opinion at all about "should this agent be allowed to submit a payment form," and site owners with no way to express that distinction have mostly responded by blocking agents outright, CAPTCHA-walling everything, and breaking the legitimate automation along with the abusive kind.
A manifest built for agents that act, not just read
The proposal gaining traction — agent-permissions.json, deliberately shaped like robots.txt so adoption doesn't require relearning a format — lets a site declare per-action policy instead of per-path access: reading is allowed, search is allowed, form submission is scoped to specific fields, a purchase requires explicit approval, account deletion is denied outright regardless of what credential shows up asking. That's a fundamentally different kind of statement than "don't crawl /admin." It's not about hiding content from a bot. It's about a site owner deciding, per action type, how much autonomy an agent gets before a human has to be in the loop.
Delegation has to be provable, not just claimed
A manifest is only useful if the agent presenting itself is actually authorized to act on the account it claims to represent — otherwise it's a bigger attack surface, not a smaller one, because now there's a documented list of exactly what an attacker's fake "agent" should claim to be able to do. The proposal handles this by extending OAuth 2.0 and OpenID Connect with agent-specific credentials and metadata, rather than inventing a new identity system from scratch: the user delegates a scoped token to their agent through the same authorization flow that already exists for third-party app access, and the website can verify that token against the manifest's rules before honoring the request. Scoped, revocable, and auditable — the same three properties any credential handed to code instead of a person should have, whether or not that code happens to be built on an LLM.
Why this differs from a rate limit or a WAF rule
Existing bot-defense tooling answers "is this traffic behaving like a bot," which is a statistical, adversarial question — and it's the wrong tool for a legitimate agent acting with explicit user consent, because a well-behaved agent completing a real purchase on a real user's behalf looks exactly like the thing the WAF was built to block. A permission manifest sidesteps the cat-and-mouse question entirely by making authorization explicit and declarative instead of inferred from behavior: the site isn't guessing whether this is a bot, it's checking whether this specific, authenticated agent has permission for this specific action, the same way an API checks a scope on a token rather than trying to guess intent from request patterns.
The gap this closes, and the one it doesn't
What a manifest buys you is a shared, machine-readable vocabulary for "what's allowed here" — the thing missing entirely right now, forcing site owners into a binary choice between blocking every agent or trusting all of them equally. What it doesn't solve on its own is verification at scale: a manifest is a promise from the site about its own policy, and a credential is a promise about who's asking, but neither one guarantees the agent enforcing "requires-approval" on its own end will actually stop and ask a human before proceeding. That half of the problem is architectural, on the agent's side, and it's the same discipline the rest of this governance conversation keeps landing on — the standard can describe the rule, but something still has to be built to actually honor it.