AI Manifest: Embedded Workflow Instructions for AI Agents

Introduction Large Language Model (LLM)-based AI agents increasingly interact with web services via browser-automation protocols such as the Model Context Protocol (MCP), Playwright, Puppeteer, and Selenium WebDriver. Current agents typically parse entire DOM trees or screenshots on every page to infer UI structure, producing three well-known problems:

Substantial token consumption due to repeated analysis of large DOMs on every session.
High failure rates on complex multi-step transactional UIs such as enterprise resource planning (ERP) systems, academic manuscript submission portals, and government e-services.
Absence of a standardized mechanism for a website operator to declare an AI-agent-friendly ("AI-Ready") operational surface.

Related prior work includes robots.txt, llms.txt, agents.txt, and ai-plugin.json. These address crawling permissions, LLM-friendly documentation, agent capability declarations, and API-level integration respectively. None provides step-by-step UI workflow instructions for multi-page transactional flows. AI Manifest fills this gap by specifying a JSON format that enumerates ordered UI operations keyed to CSS selectors. An AI agent detects, parses, and verifies the manifest before executing the listed steps, and avoids further DOM-based inference for those steps.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

AI Manifest: A structured data object, expressed in JSON, that a website operator embeds into a web page or serves at a well-known URI, containing at minimum a task identifier, an ordered steps array, and for each step an action field and a CSS selector.
AI Agent: A software process, typically driven by an LLM, that accesses a web page via a browser-automation tool and executes actions on behalf of a human user.
Central Trust Registry: A network service that stores SHA-256 hash values of manifests pre-registered by publishers, and responds to real-time trust lookups from AI agents with a status of white-listed, black-listed, or unknown.
Canonical Form: The representation of an AI Manifest obtained by lexicographically sorting all JSON object keys at every nesting level and serializing the result using the JSON encoding defined in with UTF-8.

Protocol Overview

Embedding Methods A website MAY provide an AI Manifest via one or more of the following methods:

Method A: Well-Known URI The server SHOULD make the manifest retrievable at the following well-known URI : In addition, the HTML document SHOULD declare the entry point via an HTML meta element: ]]>

Method B: Hidden DOM Element The server MAY embed the manifest into the HTML response as a hidden element with the display:none style and aria-hidden="true" attribute: ]]>

Method C: HTTP Response Header The server MAY declare the manifest location and hash in a response header: ]]> Method C is RECOMMENDED in conjunction with Method A, so that an AI agent can discover the manifest URL and validate the hash in a single request-response round trip before fetching the body.

Manifest Schema An AI Manifest is a JSON object with the following top-level fields:

version (string, REQUIRED): Specification version. This document defines version "1.0".
publisher (string, REQUIRED): Canonical domain name of the publishing website.
manifestId (string, REQUIRED): Stable identifier scoped to the publisher, used for registry lookup.
registry_url (string, REQUIRED): HTTPS URL of the trust registry that the publisher has pre-registered this manifest with.
task (object, REQUIRED): Contains a task-level id and an ordered steps array. Each element of steps is an object with at least step (integer), action (string), and selector (string). The action value MUST be one of the registered actions (see ).

Agent Detection Algorithm Upon loading a page, an AI agent implementing this specification SHOULD perform the following detection sequence before any full-DOM inference pass:

Inspect the HTTP response headers for X-AI-Manifest (Method C).
If absent, retrieve /.well-known/ai-manifest.json (Method A) or resolve the URI declared by the meta element.
If still absent, search the DOM for an element with id="ai-manifest" and read its data-manifest attribute (Method B).
If none is found, fall back to conventional DOM-based inference.

Canonical Hash and Trust Verification Prior to execution, the AI agent MUST compute a SHA-256 hash over the canonical form (see ) of the manifest and send a trust lookup request to the URI in the registry_url field. The request MUST use HTTPS and MUST carry the tuple {publisher, manifestId, hash} as a JSON body. The registry response is a JSON object containing a status field with one of the following values:

"white" — the manifest is trusted; the agent MAY proceed to execution.
"black" — the manifest is explicitly distrusted; the agent MUST abort and SHOULD alert the human user.
"unknown" — the manifest is not registered; the agent SHOULD warn the user and MAY fall back to DOM-based inference.

Implementations MAY cache a non-expired registry response keyed by the manifest hash, to avoid repeated network round trips for an identical manifest.

Execution When trust is confirmed, the agent executes the steps array in declared order, mapping each step's action and selector to a browser-automation primitive (e.g. "click", "fill", "select", "upload"). For the duration of a manifest-driven execution the agent SHOULD NOT perform additional LLM-based inference over the page DOM.

Central Trust Registry A Central Trust Registry accepts manifest registrations from publishers and answers real-time hash lookups from AI agents. A conforming registry SHOULD:

Store the SHA-256 hash of the canonical form of each registered manifest, together with the publisher and manifestId fields.
Perform static analysis on the submitted steps array and reject or black-list manifests whose selectors or actions match a published pattern of prompt-injection risk (for example, selectors targeting iframe elements for cross-origin form submission, or actions outside the registered action set).
Expose a community-driven mechanism for reporting and black-listing malicious manifests.

This document does not mandate a specific registry operator. Multiple interoperable registries MAY exist, and each manifest declares which registry is authoritative for it via registry_url.

IANA Considerations

Well-Known URI Registration This document requests IANA to register the following entry in the "Well-Known URIs" registry established by :

URI Suffix:: ai-manifest.json
Change Controller:: Independent Submission Stream editor
Reference:: This document
Status:: provisional
Related Information:: None

AI Manifest Actions Registry (initial) This document requests IANA to create a new registry named "AI Manifest Actions", with the following initial registrations. Registration policy: Specification Required .

click: Invoke a click event on the selected element.
fill: Type a value into a text input element.
select: Choose an option from a drop-down list element.
upload: Attach a file to a file input element.
wait: Pause for a condition or duration.
navigate: Change the current URL.
assert: Verify that a condition holds before proceeding.

Security Considerations

Prompt Injection Risk A malicious website could embed an AI Manifest whose steps array leads an AI agent to perform actions harmful to the user (for example, submitting a form to a third party with user-supplied credentials). The Central Trust Registry mechanism () is the primary mitigation. Agents MUST NOT execute a manifest whose registry lookup returns "black" and SHOULD warn the user before executing an "unknown" manifest.

Integrity of the Manifest The SHA-256 hash is computed over the canonical form of the manifest so that semantically equivalent encodings produce identical digests. Implementations MUST NOT rely on a hash computed over non-canonical bytes.

Transport Security All communication with the registry MUST use HTTPS with server authentication per . Registry operators SHOULD sign their responses with a public key published out of band so that an AI agent can verify the integrity of a cached response.

Privacy Considerations Registry lookups necessarily expose to the registry operator the fact that a particular AI agent has visited a particular publisher's manifest. Registry operators SHOULD minimize the retention of client identifiers associated with lookup requests. Agents MAY employ private, time-limited caching of registry responses to reduce the frequency of such lookups.

Implementation Status Note to RFC Editor: This section is intended to be removed prior to publication as an RFC. A reference implementation, including an example publisher server, a reference registry, two AI agent variants (DOM-analysis baseline and manifest-aware), and an automated benchmark harness, is available at under the MIT License. In the reference benchmark — a two-step ERP order-entry transaction repeated 30 times with input tokens counted via the tiktoken cl100k_base encoding — the manifest-aware agent consumed an average of 341 input tokens per task with a 100% task success rate (30 of 30 runs), while the DOM-analysis baseline consumed an average of 1887.6 input tokens with a 20% success rate (6 of 30 runs). Raw results accompany the reference implementation.

Intellectual Property Rights Disclosure The technology described in this document is the subject of Korean Patent Application No. 10-2026-0071716, filed on 2026-04-21 by the author. The applicant commits to offer any essential claims under Fair, Reasonable, and Non-Discriminatory (FRAND) terms to implementers of this specification, as declared in the project repository.

Acknowledgments The author thanks the Anthropic Claude Code, Model Context Protocol, and OpenAI function-calling communities for the empirical observations that motivated this work.