Independent Submission W. Han
Internet-Draft Individual
Intended status: Informational 15 May 2026
Expires: 16 November 2026
AI Manifest: Embedded Workflow Instructions for AI Agents
draft-han-ai-manifest-01
Abstract
This document specifies the AI Manifest protocol, a JSON-based format
for websites to declare step-by-step user interface (UI) workflow
instructions readable by autonomous AI agents. By embedding the
manifest, website operators allow AI agents using browser-automation
tools to execute multi-step transactions directly via Cascading Style
Sheets (CSS) selectors, without repeated analysis of the full
Document Object Model (DOM). The specification defines three
interoperable embedding methods, a SHA-256 canonical hash
verification procedure via a central trust registry, and security
mitigations against prompt injection attacks.
Empirical results from a reference implementation demonstrate an
81.9% reduction in input tokens consumed by the AI agent and an
increase in task success rate from 20% to 100% on a representative
multi-step transaction, compared with conventional DOM-analysis
approaches.
This document also documents an empirical finding (-01 update,
2026-04-28) that manifest embedding alone is insufficient for
autonomous execution by modern LLM agents due to prompt-injection
defenses in their system policies. A deterministic execution runtime
(referred to herein as the "SDK") is required to consume the verified
manifest outside the LLM reasoning loop and return only the
structured outcome to the agent. Without such a runtime, an embedded
manifest may produce negative value (slower than baseline) due to
user-approval-gate latency.
Han Expires 16 November 2026 [Page 1]
Internet-Draft AI Manifest May 2026
A -01 update (2026-05-15) introduces two additions. First, the
manifest schema is extended to the AI Friction-Recovery Manifest
(AFRM) three-part model: frameworkHints, knownTraps (primary
content), and shortcuts. This aligns with the independently observed
structure of real-world practitioner documents and with the companion
position paper (IUI 2027). Second, a fifth discovery mechanism is
specified -- Method E (AI-side curation) -- in which the user places
a manifest at a vendor-conventional file-system path (e.g.,
~/.claude/afrm/{domain}.json); the AI runtime loads it on domain
match without prompt-injection screening because the file originates
from the user's authored context. A new trap category, native-
dialog-trap, is also registered.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 16 November 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Embedding Methods . . . . . . . . . . . . . . . . . . . . 4
Han Expires 16 November 2026 [Page 2]
Internet-Draft AI Manifest May 2026
3.1.1. Method A: Well-Known URI . . . . . . . . . . . . . . 5
3.1.2. Method B: Hidden DOM Element . . . . . . . . . . . . 5
3.1.3. Method C: HTTP Response Header . . . . . . . . . . . 5
3.1.4. Method D: HTML Link Element . . . . . . . . . . . . . 5
3.1.5. Method E: AI-Side Curation . . . . . . . . . . . . . 6
3.2. Manifest Schema (AFRM Three-Part Model) . . . . . . . . . 6
3.3. Agent Detection Algorithm . . . . . . . . . . . . . . . . 7
3.4. Canonical Hash and Trust Verification . . . . . . . . . . 7
3.5. Execution . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Central Trust Registry . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1. Well-Known URI Registration . . . . . . . . . . . . . . . 8
5.2. AI Manifest Actions Registry (initial) . . . . . . . . . 9
5.3. AI Manifest Trap Categories Registry (initial) . . . . . 9
5.4. Link Relation Type Registration . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.1. Prompt Injection Risk . . . . . . . . . . . . . . . . . . 10
6.2. Interaction with LLM Agent Prompt Injection Defenses . . 10
6.3. Integrity of the Manifest . . . . . . . . . . . . . . . . 11
6.4. Transport Security . . . . . . . . . . . . . . . . . . . 11
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 12
9. Intellectual Property Rights Disclosure . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. Normative References . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. 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:
1. Substantial token consumption due to repeated analysis of large
DOMs on every session.
2. High failure rates on complex multi-step transactional UIs such
as enterprise resource planning (ERP) systems, academic
manuscript submission portals, and government e-services.
3. Absence of a standardized mechanism for a website operator to
declare an AI-agent-friendly ("AI-Ready") operational surface.
Han Expires 16 November 2026 [Page 3]
Internet-Draft AI Manifest May 2026
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.
2. 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 [RFC2119] [RFC8174] 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 [RFC8259] with UTF-8.
3. Protocol Overview
3.1. Embedding Methods
A website MAY provide an AI Manifest via one or more of the following
methods:
Han Expires 16 November 2026 [Page 4]
Internet-Draft AI Manifest May 2026
3.1.1. Method A: Well-Known URI
The server SHOULD make the manifest retrievable at the following
well-known URI [RFC8615]:
/.well-known/ai-manifest.json
In addition, the HTML document SHOULD declare the entry point via an
HTML meta element:
3.1.2. 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:
3.1.3. Method C: HTTP Response Header
The server MAY declare the manifest location and hash in a response
header:
X-AI-Manifest: url=/.well-known/ai-manifest.json;
hash=sha256:
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.
3.1.4. Method D: HTML Link Element
The server MAY declare the manifest via an HTML link element in the
document head:
Method D allows AI agents that parse the DOM but do not inspect HTTP
headers to discover the manifest location. The rel value ai-manifest
is registered in Section 5.4.
Han Expires 16 November 2026 [Page 5]
Internet-Draft AI Manifest May 2026
3.1.5. Method E: AI-Side Curation
A user MAY place a manifest at a vendor-conventional path in their
own file system, for example ~/.claude/afrm/{domain}.json or
~/.codex/afrm/{domain}.json. The AI runtime loads the file when it
visits a matching domain. Because the manifest originates from the
user's authored context, it enters the agent's trust context without
the prompt-injection screening applied to externally fetched data.
When both an AI-side curated manifest and a site-side published
manifest exist for the same origin, the curated manifest SHOULD take
precedence as the more explicit trust signal.
Method E is a transitional mechanism intended for domains that have
not yet published a site-side AFRM. Once the site publishes its own
manifest, the AI-side copy SHOULD be retired or used only to override
individual fields.
3.2. Manifest Schema (AFRM Three-Part Model)
An AI Friction-Recovery Manifest (AFRM) is a JSON object [RFC8259]
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.
frameworkHints (object, OPTIONAL) Metadata about the UI framework in
use (e.g., framework name, version, rendering model). Allows the
AI agent to apply framework-specific heuristics before
encountering friction.
knownTraps (array, REQUIRED) Primary content of the AFRM. An
ordered array of trap descriptors, each describing a UI pattern
that predictably blocks autonomous AI agents. Each element MUST
include trapId (string), category (string from the IANA trap
registry, see Section 5), selector (string), and escapeAction
(string). Optional fields include description and condition.
shortcuts (array, OPTIONAL) An array of direct navigation or action
Han Expires 16 November 2026 [Page 6]
Internet-Draft AI Manifest May 2026
shortcuts that allow the AI agent to bypass multi-step UI flows
when a direct API or deep-link equivalent exists.
3.3. 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:
1. Check the agent's local file system for a user-curated manifest
at the vendor-conventional path (e.g., ~/.claude/
afrm/{domain}.json) matching the current origin (Method E). If
found, load it into the trust context and continue; the site-side
steps below may still be consulted for supplementary data.
2. Inspect the HTTP response headers for X-AI-Manifest (Method C).
3. If absent, retrieve /.well-known/ai-manifest.json (Method A) or
resolve the URI declared by the meta element.
4. If still absent, check the document head for a element and fetch the referenced URL (Method D).
5. If still absent, search the DOM for an element with id="ai-
manifest" and read its data-manifest attribute (Method B).
6. If none is found, fall back to conventional DOM-based inference.
3.4. Canonical Hash and Trust Verification
Prior to execution, the AI agent MUST compute a SHA-256 hash over the
canonical form (see Section 2) of the manifest and send a trust
lookup request to the URI in the registry_url field. The request
MUST use HTTPS [RFC2818] 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.
Han Expires 16 November 2026 [Page 7]
Internet-Draft AI Manifest May 2026
Implementations MAY cache a non-expired registry response keyed by
the manifest hash, to avoid repeated network round trips for an
identical manifest.
3.5. 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.
4. 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.
5. IANA Considerations
5.1. Well-Known URI Registration
This document requests IANA to register the following entry in the
"Well-Known URIs" registry established by [RFC8615]:
URI Suffix: ai-manifest.json
Change Controller: Independent Submission Stream editor
Reference: This document
Status: provisional
Han Expires 16 November 2026 [Page 8]
Internet-Draft AI Manifest May 2026
Related Information: None
5.2. 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 [RFC8126].
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.
5.3. AI Manifest Trap Categories Registry (initial)
This document requests IANA to create a new registry named "AI
Manifest Trap Categories", with the following initial registrations.
Registration policy: Specification Required [RFC8126].
shadow-dom-trap A UI component rendered inside a Shadow DOM tree
whose selectors are not accessible via standard
document.querySelector calls.
virtual-scroll-trap A list or grid that renders only a visible
viewport window, requiring programmatic scrolling before off-
screen items can be targeted.
iframe-context-trap An action target located inside a cross-origin
or same-origin