Network Working Group S. Agarwal Internet-Draft 12 October 2026 Intended status: Informational Expires: 15 April 2027 Agent Context Interchange Protocol draft-agarwal-acip-00 Abstract AI coding agents obtain persistent context from organization, project, user, vendor, and task sources. Existing formats can carry prose, skills, or tool permissions, but they do not provide one interoperable resolution model for authority, file scope, enforceability, and audit evidence. This document defines the Agent Context Interchange Protocol (ACIP), a YAML-based format and host- resolution behavior for those sources. It defines source precedence, file matching, explicit distinctions between enforceable constraints, textual directives, and preferences, a resolution receipt, compatibility behavior for AGENTS.md and Agent Skills, and migration profiles for tools that do not natively support ACIP. ACIP does not claim that natural-language instructions can force an agent to behave; enforcement requires a host or external control at the action boundary. 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 15 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Agarwal Expires 15 April 2027 [Page 1] Internet-Draft ACIP October 2026 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 1.1. 1.1. Relationship to Adjacent Work . . . . . . . . . . . 4 2. 2. Conventions and Requirements Language . . . . . . . . . . 5 3. 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 4. 4. Policy Sources and Trust . . . . . . . . . . . . . . . . 6 5. 5. Policy Document Format . . . . . . . . . . . . . . . . . 7 5.1. 5.1. Discovery Locations . . . . . . . . . . . . . . . . 7 5.2. 5.2. YAML Requirements . . . . . . . . . . . . . . . . . 7 5.3. 5.3. Top-Level Members . . . . . . . . . . . . . . . . . 8 5.4. 5.4. Rule Members . . . . . . . . . . . . . . . . . . . 8 6. 6. Scope and Matching . . . . . . . . . . . . . . . . . . . 9 6.1. 6.1. Path Normalization . . . . . . . . . . . . . . . . 9 6.2. 6.2. Glob Semantics . . . . . . . . . . . . . . . . . . 10 6.3. 6.3. Operation Target Set . . . . . . . . . . . . . . . 10 7. 7. Normative Resolution Algorithm . . . . . . . . . . . . . 10 8. 8. Rule Classes and Host Enforcement . . . . . . . . . . . . 12 8.1. 8.1. Classes . . . . . . . . . . . . . . . . . . . . . . 12 8.2. 8.2. Initial Controls . . . . . . . . . . . . . . . . . 12 8.3. 8.3. No Inferred Enforcement . . . . . . . . . . . . . . 13 9. 9. Audit and Resolution Receipts . . . . . . . . . . . . . . 13 9.1. 9.1. Required Receipt Fields . . . . . . . . . . . . . . 13 9.2. 9.2. Integrity and Privacy . . . . . . . . . . . . . . . 14 9.3. 9.3. Limits of Audit Evidence . . . . . . . . . . . . . 15 10. 10. Backward Compatibility and Migration . . . . . . . . . . 15 10.1. 10.1. AGENTS.md . . . . . . . . . . . . . . . . . . . . 15 10.2. 10.2. Agent Skills and SKILL.md . . . . . . . . . . . . 15 10.3. 10.3. Migration Before Native Support . . . . . . . . . 16 10.4. 10.4. One Canonical Source . . . . . . . . . . . . . . 17 11. 11. Conformance . . . . . . . . . . . . . . . . . . . . . . 17 11.1. 11.1. Reader Profile . . . . . . . . . . . . . . . . . 17 11.2. 11.2. Context Host Profile . . . . . . . . . . . . . . 17 11.3. 11.3. Enforcement Profile . . . . . . . . . . . . . . . 17 11.4. 11.4. Audit Profile . . . . . . . . . . . . . . . . . . 18 11.5. 11.5. Adapter Profile . . . . . . . . . . . . . . . . . 18 12. 12. Security Considerations . . . . . . . . . . . . . . . . 18 12.1. 12.1. Prompt Injection and Untrusted Policy Text . . . 18 12.2. 12.2. Constraints Must Be Enforced Outside the Model . 18 Agarwal Expires 15 April 2027 [Page 2] Internet-Draft ACIP October 2026 12.3. 12.3. Policy Source and Supply-Chain Risk . . . . . . . 19 12.4. 12.4. Source Substitution, Symlinks, and Path Confusion . . . . . . . . . . . . . . . . . . . . . . . 19 12.5. 12.5. YAML Parser Risks . . . . . . . . . . . . . . . . 19 12.6. 12.6. Stale, Missing, and Conflicting Policy . . . . . 20 12.7. 12.7. Audit Log Integrity and Privacy . . . . . . . . . 20 12.8. 12.8. Denial of Service and Degraded Operation . . . . 20 12.9. 12.9. Interoperability Is Not Authorization . . . . . . 20 13. 13. IANA Considerations . . . . . . . . . . . . . . . . . . 20 13.1. 13.1. Media Type Registration . . . . . . . . . . . . . 21 13.2. 13.2. Agent Policy Classes Registry . . . . . . . . . . 22 13.3. 13.3. Agent Policy Controls Registry . . . . . . . . . 23 13.4. 13.4. Agent Policy Operations Registry . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 14.1. Normative References . . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . 26 Appendix A. Rationale and Anticipated Objections . . . . . . . . 28 A.1. 14.1. "AGENTS.md Already Solves Portability" . . . . . . 28 A.2. 14.2. "This Is Prompt Engineering, Not a Standard" . . . 28 A.3. 14.3. "One More File Adds More Staleness" . . . . . . . 28 A.4. 14.4. "A Vendor Will Ignore It Anyway" . . . . . . . . . 29 A.5. 14.5. "IETF Is Only for Wire Protocols" . . . . . . . . 29 A.6. 14.6. "Why Not Just Standardize MCP or NLIP?" . . . . . 29 A.7. 14.7. "Precedence Cannot Resolve Natural-Language Contradictions" . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 1. 1. Introduction Users currently maintain overlapping instruction artifacts for different agent products. Repository-wide guidance, path-specific rules, user defaults, organization policies, and on-demand skills are often stored in distinct formats. Their discovery, precedence, scoping, and enforcement differ by implementation. A shared filename alone would not resolve those differences. ACIP defines a portable data model and deterministic resolver. The canonical policy is stored as YAML in agent-context.yaml. A conforming host resolves organization, project, task, user, and vendor sources before acting, applies path-scoped rules only to matching operation targets, and records a receipt of the resolved inputs. A host with an enforcement profile can apply supported machine-readable constraints before tool execution. Other text remains guidance to the model and is not described as a security boundary. Agarwal Expires 15 April 2027 [Page 3] Internet-Draft ACIP October 2026 ACIP concerns persistent or reusable instructions presented to coding agents in IDEs, editors, command-line development tools, and hosted development environments. It does not define agent-to-agent task exchange, tool discovery, model behavior, a general-purpose authorization token, or the contents of a specific organization's policy. 1.1. 1.1. Relationship to Adjacent Work The Model Context Protocol (MCP) defines an integration protocol for context, resources, prompts, and tools between hosts, clients, and servers [MCP]. The Agent Client Protocol (ACP) standardizes editor- to-agent communication [ACP]. Neither defines a portable hierarchy for repository and user instruction sources. An active individual Internet-Draft proposes carrying MCP primitives and Agent Skills over Media over QUIC Transport; this is a transport mapping, not a repository policy resolver [IETFMOQT]. Agent Skills defines a portable directory and SKILL.md format for packaged, on-demand procedures and resources. It specifies skill metadata and progressive disclosure, but not authoritative rule precedence or action-boundary enforcement [AGENTSKILLS]. AGENTS.md is a broadly adopted, plain-Markdown convention. It does not define structured constraint types or a universal precedence algorithm [AGENTSMD]. Vendor formats remain product-specific. Copilot uses repository-wide and path-specific Markdown files; Claude Code combines CLAUDE.md, scoped rules, and skills; Cursor has .mdc project rules and team/user rules; Gemini uses GEMINI.md; and Cline supports conditional rules [COPILOT] [CLAUDE] [CURSOR] [GEMINI] [CLINES]. Aider loads convention files by configuration, while Junie and current Windsurf/ Devin documentation support AGENTS.md alongside product-specific rules [AIDER] [JUNIE] [WINDSURF]. The llms.txt proposal is a website documentation-navigation convention, not a coding-agent policy format [LLMS]. An expired IETF AGENTS.TXT draft concerns crawler access policy, not IDE coding-agent instructions [IETFROBOTS]. Ecma International's ECMA-430 specifies NLIP, an application-level natural language interaction protocol between agents or people and agents. ECMA-431 and ECMA-432 define HTTP and WebSocket bindings. These are formal standards for agent communication, not IDE instruction sources, repository scoping, or policy inheritance [ECMA430] [ECMA431] [ECMA432]. Agarwal Expires 15 April 2027 [Page 4] Internet-Draft ACIP October 2026 An IETF individual Internet-Draft on Agent Delegation Receipts addresses signed authorization scopes, instruction hashes, and audit limits. It is useful adjacent work but does not define how IDEs discover or combine organization, project, user, and vendor instructions [IETFAGENTS]. Internet-Drafts are work in progress and are not endorsed standards [IETFNEW]. 2. 2. Conventions and Requirements Language 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