Internet-Draft AgentManifest July 2026
Jernalczyk Expires 7 January 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-jernalczyk-intentweb-agent-manifest-00
Published:
Intended Status:
Experimental
Expires:
Author:
M. Jernalczyk
IntentWeb

IntentWeb AgentManifest

Abstract

AgentManifest defines a JSON document that websites can publish to describe identity, trusted knowledge, agent-facing capabilities, structured bindings, risk levels, consent requirements, authentication expectations, audit rules, and policies.

The goal is to help AI agents understand what a website knows and what it can safely do before scraping, guessing from visual UI, or executing brittle browser automation.

Note to Readers

This note is to be removed before publishing as an RFC.

This document is an experimental individual Internet-Draft proposal for discussion. It is not an RFC and is not an IETF-approved standard.

Source material for this draft is maintained in the AgentManifest repository. The draft is expected to change based on implementation feedback and standards discussion.

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 7 January 2027.

Table of Contents

1. Introduction

AgentManifest is an experimental open specification. Implementers are encouraged to test the draft, report interoperability issues, and propose improvements.

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Overview

An AgentManifest document declares:

Capabilities describe what a website can do and under which policy. Structured bindings describe how that capability can be accessed or executed, such as through HTML, static resources, HTTP, OpenAPI , MCP , or hosted checkout. OpenAPI operations and MCP tools are binding targets, not the whole capability contract.

AgentManifest is vendor-neutral. Implementation frameworks can generate manifests and bindings, but the manifest does not require any specific generator or expose implementation ownership as a normative field.

3. Discovery

Agents SHOULD attempt static discovery at /.well-known/agent.json. Publishers MAY also expose /.well-known/agent-manifest.json, /agent-manifest.json, or an HTML discovery hint:

<link rel="agent-manifest" href="/.well-known/agent.json">

If no manifest is found, agents SHOULD continue normal web behavior and SHOULD NOT infer that unsupported actions are safe.

4. Schema

The canonical JSON Schema for the repository version of this draft is:

rfc/schemas/agent-manifest.v0.1.schema.json

The schema uses JSON Schema Draft 2020-12 and keeps additionalProperties: true for forward-compatible experimentation.

A conforming manifest for this draft uses the agentManifestVersion value 0.1-draft.

6. Security Considerations

Manifests and related public files MUST NOT expose secrets, private tokens, unpublished data, private customer information, admin-only endpoints, or privileged internal operations.

Servers MUST enforce authorization, consent, validation, replay protection, duplicate transaction controls, and policy checks outside prompt text. Prompt instructions are not a security boundary.

7. Privacy Considerations

Publishers should minimize disclosed and collected data. Knowledge sources should include only information intended for public agent use. State-changing actions should collect only fields required for the declared capability.

Agents should provide user-visible summaries for submitted data and should avoid logging sensitive user information unless required for audit, compliance, or fraud prevention.

8. IANA Considerations

This document makes no IANA registration request.

The media type application/agent-manifest+json is proposed for discussion only and is not registered by this document.

9. Normative References

[JSON-SCHEMA-2020-12]
JSON Schema, "JSON Schema: A Media Type for Describing JSON Documents", , <https://json-schema.org/draft/2020-12/json-schema-core.html>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

10. Informative References

[MCP]
Model Context Protocol, "Model Context Protocol", <https://modelcontextprotocol.io/>.
[OPENAPI]
OpenAPI Initiative, "OpenAPI Specification", <https://spec.openapis.org/oas/latest.html>.

Author's Address

Mariusz Jernalczyk
IntentWeb