# agent-permissions.json A robots.txt-inspired standard for how agents may interact with webpages. Made with ❤️ by the [Lightweight Agent Standards Working Group](https://las-wg.org/). Note: This standard is still WIP! If you're interested in contributing, join our [Discord](https://discord.gg/wmRSNHsRAh)! --- # Introduction Websites need a machine-readable, non-binding way to declare how automated agents (bots, crawlers, assistants) may interact with them. This **JSON-only Agent Permissions File** lets sites express fine-grained resource-level rules and higher-level action guidelines in a single, versioned document. This document does not cover agent-to-agent interactions or content usage policies (see [IETF AIPref](https://datatracker.ietf.org/wg/aipref/about/) instead). The key words **“MUST”**, **“MUST NOT”**, **“SHOULD”**, and **“SHOULD NOT”** are to be interpreted as described in RFC 2119. This file is advisory and non-binding: agents MAY choose stricter behaviors than those granted here, but MUST NOT exceed the permissions granted if they claim to honor this format. # File Discovery Consumers **MAY** locate and fetch the JSON policy via a link tag, e.g.: ```html ``` In case of no `` tag, the default path is `/.well-known/agent-permissions.json`. Servers **SHOULD** serve this file with `Content-Type: application/json`. # Rationale There are two forms of permissions: * **Resource permissions**: how you can interact with HTML elements (clicking, following links, filling forms, controlling media, uploading files…). * **Action permissions**: what you can do on the web page (sending DMs, booking a flight, posting content…). The former are described using `resource_rules`, which is a list containing, for each element: * A `verb` (e.g., `"click_element"` or `"follow_link"`) * A CSS selector that restricts what the rule applies to * Whether the action is `allowed` or forbidden * (Optionally) `modifiers`, e.g. a limit on how many actions can be performed at the same time or whether it requires explicit user consent The top-level field `strict` prescribes the default behavior for an action that is not explicitly allowed or forbidden (`true`: defaults to forbidden, `false`: defaults to allowed). The latter are described using `action_guidelines`, which is a list containing, for each element: * An RFC-2119 style `directive` (`"MUST"`, `"MUST NOT"`, `"SHOULD"`, `"SHOULD NOT"`) * A natural language `description` of the action (e.g. “Book a flight”) * A natural language description of `exceptions` Implementation-wise, agents can follow `resource_rules` at the interface level (e.g. if the agent is using a headless browser to perform an action, the code connecting the agent to the browser can act as an enforcement layer), while `action_guidelines` are provided as prompt or configuration to the agent. Some higher-level behaviors (for example, “fill this form”) are expected to be **composite** operations built from primitive verbs (e.g. multiple `set_input_value` calls followed by `submit_form`). Finally, the field `api` provides information on what actions can be performed by calling HTTP APIs (e.g. REST) instead of interacting with the website, as the former is often more efficient and reliable than the latter. # Verbs The `verb` in each `resource_rules` entry MUST be one of the following values. Future versions MAY extend this list; unknown verbs MUST be treated as disallowed. * **`all`** Wildcard for all verbs. * **`read_content`** Read the human-visible content of elements on the page (main body text, headings, labels, etc.). * **`read_metadata`** Read non-body metadata associated with the page (e.g. `