Agent Context Interchange Protocol
draft-agarwal-acip-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Shubham Agarwal | ||
| Last updated | 2026-10-12 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-agarwal-acip-00
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 only when, they appear in all
capitals, as shown here.
ACIP defines normative requirements for policy-file parsers,
resolvers, host integrations, and adapters. It does not convert the
prose inside a policy file into IETF requirements or make a language
model a trusted enforcement mechanism.
3. 3. Terminology
*Agent:* A software system that uses a model to plan or perform
development work, potentially invoking tools that read or modify a
workspace.
*Host:* The IDE, editor, CLI, service, or other component that
selects an agent, supplies its context, and mediates its tools.
*Policy source:* A document or managed configuration supplied at one
of the authority levels defined in this specification.
*Authority level:* The source's rank, determined by the host from its
provenance, not from a field claimed by the file.
*Rule:* A uniquely identified ACIP entry with a class, a scope, and
either text, an enforcement declaration, or both as permitted by this
specification.
*Constraint:* A machine-readable rule that a conforming enforcement
host can apply to an operation before that operation executes.
*Directive:* Textual guidance intended to influence an agent. A
directive is not an enforcement mechanism.
*Preference:* Optional textual guidance that yields to a conflicting
directive or constraint.
Agarwal Expires 15 April 2027 [Page 5]
Internet-Draft ACIP October 2026
*Task instruction:* The instructions supplied by the human for the
current task, distinct from persistent user-level preferences.
*Target path:* A normalized, workspace-relative path that an
operation will read, write, or otherwise act on.
*Resolution receipt:* A record of the exact policy source versions,
matching rules, precedence decisions, and enforcement results used
for an action.
*Adapter:* A host-specific component that reads ACIP or materializes
a vendor's native instruction representation from it.
4. 4. Policy Sources and Trust
Each policy source has a provenance level assigned by the host:
1. *Organization:* Policy delivered by a host's administrator-
managed policy channel or an equivalent operating-system-managed
location.
2. *Project:* Policy checked into the repository or supplied by the
repository's trusted workspace configuration.
3. *Task:* Instructions supplied for the current request by the
human initiating that task.
4. *User:* Persistent preferences configured by the individual user.
5. *Vendor:* Product defaults and vendor-specific instructions not
supplied by a higher-ranked source.
The host MUST determine source provenance independently of policy-
file contents. A project file MUST NOT claim organization authority
by setting a field in the file. A host MUST keep organization-
managed policy separate from project-controlled storage so that a
repository change cannot impersonate or replace an organization
policy.
Organization policy discovery is host-specific because operating
systems and enterprise management systems do not share a portable
global configuration location. A host that supports organization
policy MUST expose the source and its revision in the resolution
receipt. A host without such a mechanism MAY omit the organization
source and MUST report that limitation when claiming ACIP
conformance.
Agarwal Expires 15 April 2027 [Page 6]
Internet-Draft ACIP October 2026
The host MUST apply any stronger safety or permission policy supplied
by its platform outside ACIP. ACIP source ordering does not grant a
policy file authority to override host safeguards, model-provider
safety constraints, or user-consent requirements imposed by the host.
5. 5. Policy Document Format
5.1. 5.1. Discovery Locations
The canonical project policy is .agents/agent-context.yaml at the
repository root. A project MAY place additional ACIP files in
.agents/policies/. Their source level is Project. A host MUST
discover only files inside the trusted repository root and MUST
associate each discovered file with its canonical repository-relative
path.
The canonical user policy is $XDG_CONFIG_HOME/agent-context/agent-
context.yaml when XDG_CONFIG_HOME is set. Otherwise, a host MUST use
the platform's documented user configuration directory and disclose
that location in its conformance documentation. On Windows,
%APPDATA%\\agent-context\\agent-context.yaml is the default.
Organization-level policy is supplied through the managed policy
interface described in Section 4.
An implementation MAY support other discovery locations, but MUST
treat them as aliases for one of the five provenance levels. It MUST
NOT infer higher authority from a path name chosen by the file
author.
5.2. 5.2. YAML Requirements
A ACIP file MUST be one YAML 1.2 document, encoded as UTF-8. It MUST
use only the JSON-compatible YAML data model: mappings with string
keys, sequences, strings, booleans, null, and finite numbers. A
parser MUST reject custom tags, duplicate mapping keys, non-string
mapping keys, cyclic aliases, multiple YAML documents, and
unsupported values. A parser MUST enforce finite limits on file
size, nesting depth, alias expansion, and scalar length. These
restrictions avoid ambiguous and unsafe YAML processing [RFC9512]
[YAML].
Unknown top-level fields MUST cause a validation error. A host MUST
NOT silently reinterpret malformed YAML as plain instructions. A
host that cannot parse an organization or project file MUST emit a
visible error and, in the Enforcement profile, deny mutating
operations whose policy status cannot be resolved until the file is
corrected or an authorized administrator explicitly disables it.
Agarwal Expires 15 April 2027 [Page 7]
Internet-Draft ACIP October 2026
5.3. 5.3. Top-Level Members
The top-level mapping contains:
* format: REQUIRED integer. The initial value is 1.
* policy_id: REQUIRED stable string unique within the source
authority.
* rules: REQUIRED sequence of Rule objects. An empty sequence is
valid.
* expires: OPTIONAL UTC timestamp. An expired policy MUST NOT be
treated as current. The host MUST report the expiration.
The following example is illustrative:
<CODE BEGINS> ~~~yaml format: 1 policy_id: example.project rules: -
id: no-secret-writes class: constraint scope: paths: - "secrets/*"
text: "Do not modify credential material." controls: - control: deny-
operation operation: file.write - id: python-style class: directive
key: source-style scope: paths: - "*/*.py" text: >- Follow existing
Python style and typing conventions. - id: concise-diffs class:
preference key: response-style scope: paths: - "**" text: "Prefer
small, focused changes." ~~~ <CODE ENDS>
5.4. 5.4. Rule Members
Every Rule MUST contain:
* id: REQUIRED stable identifier, unique within the containing
policy.
* class: REQUIRED value from the Agent Policy Classes registry.
* scope: REQUIRED mapping containing paths, a non-empty sequence of
glob patterns. An omitted or empty path scope is invalid. Use
"**" for all workspace paths.
* key: REQUIRED string for directive and preference rules. It MUST
be between 1 and 128 ASCII characters. It MUST start with a
lowercase letter or digit and contain only lowercase letters,
digits, periods, underscores, or hyphens. It MUST be omitted for
constraint rules.
* text: OPTIONAL string delivered as model context. It MUST be
present for directive and preference rules. It MAY accompany a
constraint as explanatory text.
Agarwal Expires 15 April 2027 [Page 8]
Internet-Draft ACIP October 2026
* controls: REQUIRED non-empty sequence for constraint rules. It
MUST be omitted for directive and preference rules.
For directive and preference rules, key is REQUIRED. It identifies
the semantic topic for deterministic selection, such as source-style
or test-command. Two such rules with the same key are alternative
guidance, not automatically composable text. A resolver MUST choose
one winner according to Section 7, or report an unresolved conflict.
An implementation MUST NOT ask the model to decide which authority
source wins.
For constraint rules, controls is REQUIRED and MUST contain one or
more entries from the Agent Policy Controls registry. A constraint
MAY NOT be represented solely by natural-language text. If a host
does not implement a control used by an applicable constraint, it
MUST report the unsupported control and deny the affected operation
in the Enforcement profile.
Each control entry is a mapping with control, the registered control
token, and the parameters defined for that token. The initial
controls require an operation string containing a registered
operation token. deny-operation and require-approval MAY also contain
paths, a non-empty sequence of glob patterns evaluated using
Section 6. A control applies only when both the containing Rule's
scope.paths and the control's optional paths match at least one
operation target. A host MUST reject a control entry containing an
unknown member or missing a required parameter.
Unknown Rule members MUST cause a validation error unless a future
version of this specification defines an extension point for them. A
host MAY preserve unknown members for round-trip editing but MUST NOT
treat them as effective policy.
6. 6. Scope and Matching
6.1. 6.1. Path Normalization
All ACIP paths are relative to the repository root and use / as the
separator. A resolver MUST remove leading ./ components, collapse
redundant separators, and reject absolute paths, empty paths, NUL
characters, and paths containing a .. component. Matching is case-
sensitive, including on case-insensitive filesystems. A host MUST
compare paths in a consistent Unicode-normalized form and MUST
document the normalization form it uses.
Agarwal Expires 15 April 2027 [Page 9]
Internet-Draft ACIP October 2026
An operation through a symbolic link MUST be matched using both the
workspace-relative path presented to the agent and the resolved
target path. If the resolved target escapes the repository root, a
project policy MUST NOT be allowed to grant access to it.
Organization and user controls still apply.
6.2. 6.2. Glob Semantics
The ACIP glob grammar is intentionally small:
* * matches zero or more characters other than /.
* ? matches exactly one character other than /.
* ** matches zero or more characters, including /.
* Two asterisks followed by a slash at the start of a pattern match
zero or more complete path components.
* All other characters match themselves. Character classes, brace
expansion, negation, and implementation-specific extensions are
not defined.
Patterns are anchored to the entire normalized path. A resolver MUST
use these semantics and MUST NOT delegate interpretation to a
platform-specific glob library with different behavior.
6.3. 6.3. Operation Target Set
The host MUST determine the set of target paths for an operation from
the actual tool request, not merely from open tabs, visible editor
contents, or paths mentioned in natural language. A rule applies
when at least one target path matches at least one pattern. A rule
with "**" applies to every workspace path.
If an operation has no known target path, only rules scoped to "**"
apply to that operation. Before an operation with a newly determined
target path executes, the host MUST recompute the applicable rules.
The host MUST NOT use an earlier resolution receipt as proof that a
different target was checked.
7. 7. Normative Resolution Algorithm
The algorithm in this section defines how a conforming resolver
builds the effective instruction set for an operation. It is
deterministic for the same policy source bytes, provenance, task
input, target paths, and host profile.
Agarwal Expires 15 April 2027 [Page 10]
Internet-Draft ACIP October 2026
1. *Discover sources.* Load available organization, project, task,
user, and vendor sources. Record each source's authority,
location or provider, revision identifier, and content digest.
Do not trust authority claims in source contents.
2. *Validate sources.* Parse each ACIP document under Section 5.
Reject malformed documents as specified in Section 5.2. Load
legacy inputs only under Section 10.
3. *Normalize operation targets.* Compute the complete set of known
target paths using Section 6. If the action changes its target
set, restart resolution before execution.
4. *Filter by scope.* Retain only rules whose path scope matches at
least one operation target, or whose scope is "**" when no path
is known.
5. *Apply constraints.* Combine all applicable constraints from all
authorities. A lower authority MUST NOT remove or weaken a
higher authority's constraint. A matching deny takes precedence
over a matching approval requirement. If any applicable
constraint denies an operation, the host MUST deny the operation.
If required approval is absent, the host MUST pause the operation
and obtain it through its normal trusted approval mechanism.
6. *Select textual guidance.* For each key used by applicable
directive or preference rules, select the winner by the following
tuple, in descending order: source authority (Organization,
Project, Task, User, Vendor); class (directive before
preference); scope specificity. Scope specificity is ordered by:
exact literal path, then the number of literal path components,
then the lower count of wildcard operators. If otherwise tied,
multiple candidates at the same authority, class, and specificity
are an unresolved conflict; the host MUST surface the conflict
and MUST NOT ask the model to resolve it. A higher-ranked rule
for the same key supersedes a lower-ranked rule for that key. No
file-order tie-break is permitted.
7. *Build model context.* Present the selected directives and
preferences in descending precedence, with source, class, key,
and scope provenance visible to the agent. Constraints MUST also
be represented in the host's enforcement layer; model-context
text alone is insufficient.
Agarwal Expires 15 April 2027 [Page 11]
Internet-Draft ACIP October 2026
8. *Record resolution.* Create a resolution receipt as described in
Section 9 before any action is executed. Record unsupported
policy features and unresolved conflicts. An unresolved conflict
affecting the requested action MUST block that action until the
conflict is resolved.
9. *Enforce at the boundary.* Before every mutating or externally
visible operation, evaluate applicable controls against the
concrete operation and its target set. A denied action MUST NOT
be sent to the tool. Record the decision and the policy revision
used.
The operation's user request does not waive an applicable constraint.
A lower-authority source MUST NOT waive or weaken a higher-authority
constraint. An authorized source can update or remove constraints it
owns by publishing a new revision of that source. A host's external
safety controls cannot be waived by ACIP.
The resolver MUST preserve the raw policy source bytes or an
immutable content-addressed reference to them for the lifetime of the
resolution receipt. If two rules have the same key and equal rank/
specificity, the resolver MUST report a conflict rather than use file
order or a lexical tie break.
8. 8. Rule Classes and Host Enforcement
8.1. 8.1. Classes
constraint is a structured operation boundary. It is enforceable
only when the host implements the referenced control at the action
boundary.
directive is prose intended to guide agent planning or output. A
host MUST present it to the agent as guidance but MUST NOT claim that
it is enforced.
preference is optional prose. It is subordinate to conflicting
directives at the same authority and to all applicable constraints.
A policy author MUST NOT label prose-only requirements as constraint.
A conformance statement MUST distinguish runtime enforcement from
prompt injection of natural-language text.
8.2. 8.2. Initial Controls
The initial Agent Policy Controls registry contains:
Agarwal Expires 15 April 2027 [Page 12]
Internet-Draft ACIP October 2026
* deny-operation: Denies the named operation. An optional paths
sequence limits the denial to matching target paths; without
paths, the denial applies to every operation instance within the
rule's scope.
* require-approval: Requires explicit host-mediated human approval
for the named operation before execution. An approval is valid
only for the exact operation request authorized by the host. The
host MUST bind approval to the operation token, normalized target
paths, and the complete operation parameters. Any change to one
of these values requires new approval.
When multiple controls apply, the host MUST evaluate all applicable
deny-operation controls first. If any matches, the result is deny
and no approval prompt is issued. Otherwise, the host MUST collect
approval for each distinct operation request covered by one or more
require-approval controls before invoking the tool.
The operation names used by controls are drawn from the Agent Policy
Operations registry. Implementations MUST fail closed when an
applicable operation name or control is unknown. At minimum, an
Enforcement-profile host MUST implement file.read, file.write,
file.delete, process.exec, and network.connect at its actual tool
boundary. A host that cannot mediate a tool MUST NOT claim
enforcement for operations performed by that tool.
8.3. 8.3. No Inferred Enforcement
Neither a filename, a MUST word in prose, a trusted skill name, nor
an agent's apparent acknowledgment constitutes enforcement.
Enforcement means that the host checks the actual tool operation and
can prevent it from reaching the tool. External controls such as
filesystem permissions, sandboxing, command allowlists, and CI policy
remain necessary where a host cannot mediate an action.
9. 9. Audit and Resolution Receipts
9.1. 9.1. Required Receipt Fields
For every action taken by a host claiming the Audit profile, the host
MUST record a receipt containing:
* unique action and session identifiers;
* timestamp and host/adapter implementation identifier and version;
* workspace identity and revision, when available;
Agarwal Expires 15 April 2027 [Page 13]
Internet-Draft ACIP October 2026
* a digest of the effective instruction payload supplied to the
model and, for adapters, a digest of the generated vendor-format
payload;
* each discovered policy source's provenance level, source
identifier, revision or immutable content reference, and
cryptographic digest;
* each applicable rule's source identifier, rule identifier, class,
scope, and selection outcome;
* a digest or protected reference to the current task request and
other non-policy context sources that can affect the action;
unavailable vendor system context MUST be marked as unavailable,
not implied to be covered;
* textual instruction digests and an indication of whether the exact
source bytes are retained;
* the normalized target paths and operation name;
* enforcement controls evaluated and their permit, deny, approval,
or unsupported outcomes, including attempted operations denied
before tool invocation; and
* any parse errors, precedence conflicts, unsupported controls, or
legacy translations.
The receipt MUST distinguish "loaded into model context" from
"enforced by the host". It MUST NOT claim that the agent obeyed an
instruction merely because the instruction was loaded. A deployment
that needs reconstruction MUST retain the referenced policy bytes in
an access-controlled archive or another content-addressed store for
the documented retention period.
9.2. 9.2. Integrity and Privacy
An implementation SHOULD use append-only storage with hash chaining
and should sign or otherwise externally anchor receipt batches. The
signing key and trust mechanism are outside the file format and MUST
be documented by the deployment. A receipt without an authenticated
trust anchor proves only what the local logger recorded.
Agarwal Expires 15 April 2027 [Page 14]
Internet-Draft ACIP October 2026
Receipts SHOULD record hashes and source references rather than
duplicate instruction text. If text is included to enable later
reconstruction, it MUST be protected at rest and access-controlled.
Implementations MUST NOT include credentials, secrets, private prompt
content, or unrelated source file content in receipts. Retention and
deletion requirements MUST be documented.
9.3. 9.3. Limits of Audit Evidence
A resolution receipt can establish which source versions the host
selected, which rules matched, how precedence was resolved, and what
enforcement gate decision the host recorded. It cannot establish the
model's private reasoning, prove that natural-language guidance
caused a particular output, or prove that a compromised host actually
blocked an operation. A signed receipt is evidence of a host
assertion, not proof of correct model behavior or of a trustworthy
host.
10. 10. Backward Compatibility and Migration
10.1. 10.1. AGENTS.md
A conforming resolver MUST continue to discover AGENTS.md in the
project root and in nested project directories. A legacy file's
effective path scope is the subtree rooted at the directory
containing that file. The resolver MUST associate it with Project
authority and class directive; it MUST NOT infer machine enforcement
from Markdown wording. The host MUST include its source path and
digest in the resolution receipt.
When a ACIP directive with the same key supersedes a migrated legacy
directive, the resolver MUST avoid duplicate injection. Since legacy
Markdown has no standard topic key, an adapter MAY treat all legacy
content at the same directory as the reserved key legacy.agents-md;
it MUST report this coarse grouping in the receipt.
10.2. 10.2. Agent Skills and SKILL.md
An implementation MUST preserve Agent Skills discovery, metadata,
activation, and progressive-disclosure behavior. A SKILL.md body is
not an always-on policy source merely because it exists. When a
skill is activated, its content is an additional Project, User,
Organization, or Vendor directive according to its independently
established provenance. A skill MUST NOT override an applicable ACIP
constraint. Experimental or vendor-specific skill metadata MUST NOT
be interpreted as ACIP enforcement unless the relevant control is
implemented by the host.
Agarwal Expires 15 April 2027 [Page 15]
Internet-Draft ACIP October 2026
10.3. 10.3. Migration Before Native Support
ACIP adoption does not require waiting for every vendor to add a
native parser. A transition adapter can read .agents/agent-
context.yaml, resolve scopes and precedence, and materialize the
selected textual instructions into the target's existing input
format. It can be run before launching an agent, from an IDE task,
or in a wrapper script. Generated files MUST be marked as generated
and MUST NOT become independent authoring sources.
An adapter MUST report unsupported fields and lossy translations. It
MUST NOT translate a ACIP constraint into prose and then claim that
constraint is enforced. For a vendor without an action-boundary API,
the adapter can supply context but cannot guarantee compliance. In
that environment, users can still author once and use generated
native files, but they do not receive the Enforcement profile or a
complete audit proof.
Vendor adapters SHOULD support these common projections:
* AGENTS.md for root and nested project directives;
* GitHub Copilot repository and path-specific instruction files;
* CLAUDE.md and .claude/rules/;
* Cursor rule files under .cursor/rules with the .mdc extension;
* Gemini GEMINI.md;
* Windsurf/Devin .devin/rules/ and legacy .windsurf/rules/;
* Cline .clinerules/;
* Aider read-only conventions configuration; and
* Junie AGENTS.md and .junie/rules/ or guidelines.
The output of a text-only adapter is advisory regardless of the
source rule's original class. An adapter that cannot preserve
authority ordering MUST fail with a loss report rather than silently
merge conflicting text.
Agarwal Expires 15 April 2027 [Page 16]
Internet-Draft ACIP October 2026
10.4. 10.4. One Canonical Source
During migration, the ACIP file is the sole authoring source.
Existing native files may remain as generated compatibility outputs.
Teams SHOULD add a CI check that verifies generated files are current
and rejects manual edits to generated outputs. An adapter MAY also
generate an AGENTS.md summary that points to the canonical source for
tools that support dynamic file imports, but MUST NOT rely on a
natural-language instruction to cause an agent to read an arbitrary
file.
11. 11. Conformance
An implementation claiming conformance MUST identify its profile,
supported source levels, operation types, supported controls, legacy
formats, and known limitations. It MUST pass a public test suite
covering YAML validation, path normalization, glob semantics, source
precedence, rule selection, constraint denial, approval handling, and
receipt contents.
11.1. 11.1. Reader Profile
A Reader parses and validates ACIP, discovers project and user
sources, and applies Sections 5-7. It MUST report malformed files
and unresolved conflicts. It does not claim that prose rules or
constraints are enforced.
11.2. 11.2. Context Host Profile
A Context Host conforms to the Reader profile and supplies the
selected directives and preferences to the agent in the specified
order. It MUST identify their source and class to the agent. It
MUST NOT claim that natural-language instructions are action-boundary
controls.
11.3. 11.3. Enforcement Profile
An Enforcement host conforms to the Context Host profile, implements
every control it claims, mediates the operations it claims to
protect, and evaluates controls before tool execution. It MUST
default-deny unsupported constraints and MUST record the enforcement
result. A host may claim support for a subset of tools only if that
limitation is prominent in its conformance statement.
Agarwal Expires 15 April 2027 [Page 17]
Internet-Draft ACIP October 2026
11.4. 11.4. Audit Profile
An Audit host conforms to the Context Host profile and records
receipts as specified in Section 9 for each action. A receipt MAY be
signed and hash-chained. The host MUST state what its integrity
mechanism proves and what it does not prove.
11.5. 11.5. Adapter Profile
An Adapter reads ACIP and emits a named vendor format. It MUST
implement the source precedence and scope selection before
projection, preserve the selected provenance in emitted output when
the target format permits, and emit a machine-readable loss report.
A text-only projection cannot claim Enforcement-profile conformance.
12. 12. Security Considerations
12.1. 12.1. Prompt Injection and Untrusted Policy Text
Project-controlled instructions are potentially adversarial,
particularly when a host opens an untrusted repository, processes a
pull request, or runs an agent against a branch controlled by another
party. A repository may contain instructions that impersonate system
messages, ask the agent to reveal secrets, disable safeguards, or
modify its own policy. The host MUST present the provenance level
and path of project rules and MUST NOT treat Markdown or YAML text as
privileged system policy. A user or organization trust decision is
required before granting project rules the ability to influence a
session.
Textual directives and preferences remain prompt-injection inputs.
Hosts SHOULD delimit and label policy text as untrusted context,
preserve its origin, and prevent it from being concatenated into a
privileged system instruction channel. Rules that request secrets,
credentials, tool permission changes, instruction-file changes, or
policy-source changes SHOULD receive heightened scrutiny. Project
content, tool output, retrieved documents, commit messages, code
comments, and skill content MUST NOT be allowed to change a source's
authority rank.
12.2. 12.2. Constraints Must Be Enforced Outside the Model
An LLM can ignore, misinterpret, or be manipulated into violating
prose. Consequently, a textual "never" or "MUST NOT" does not
provide access control. Implementers MUST enforce security-sensitive
constraints in a host, sandbox, permission broker, filesystem,
network boundary, or other mechanism that can prevent the operation.
A host MUST NOT describe prompt injection as equivalent to a deny
Agarwal Expires 15 April 2027 [Page 18]
Internet-Draft ACIP October 2026
rule. If an operation bypasses the host, ACIP cannot protect it.
12.3. 12.3. Policy Source and Supply-Chain Risk
Policy files can be modified through compromised repositories,
malicious pull requests, compromised accounts, poisoned packages, or
altered vendor updates. Organization policies SHOULD be delivered
through authenticated, administrator-controlled channels. Hosts
SHOULD pin policy revisions and record content digests. Repositories
SHOULD review changes to ACIP and legacy instruction files as
security-sensitive code changes.
Skills can contain executable scripts, templates, referenced
documents, and tool-permission metadata. A skill is a software
supply-chain input, not trusted merely because its directory is named
skills. Hosts SHOULD require review or explicit trust before
activating a skill from an untrusted source, pin third-party skills
to immutable versions or digests, and apply the same permission and
sandbox controls to skill scripts as to other code. ACIP parsers
MUST NOT execute scripts or fetch remote includes while resolving a
policy.
12.4. 12.4. Source Substitution, Symlinks, and Path Confusion
An attacker may try to place a policy outside a workspace and reach
it through a symlink, path traversal, case-folding collision, Unicode
normalization collision, or repository-root ambiguity. Resolvers
MUST normalize paths as specified in Section 6, reject traversal,
bind project sources to the identified repository root, and record
both presented and resolved paths. When the host cannot establish a
safe path identity, it MUST NOT apply the project policy to an out-
of-root target.
12.5. 12.5. YAML Parser Risks
YAML permits features that can cause code execution in unsafe
parsers, resource exhaustion, or semantic differences among
implementations. ACIP prohibits custom tags, cyclic aliases,
duplicate keys, multiple documents, and non-JSON data-model values.
Implementations MUST use a safe parser and impose resource limits.
They MUST validate the entire document before applying any rule;
partial parse success MUST NOT result in a partial allow.
Agarwal Expires 15 April 2027 [Page 19]
Internet-Draft ACIP October 2026
12.6. 12.6. Stale, Missing, and Conflicting Policy
Stale instructions can be worse than no instructions. Hosts SHOULD
report expired policies and repository revisions that differ from
those recorded in the current session. Constraints with unresolved
conflicts or unsupported controls MUST fail closed for affected
operations. For directives and preferences, a host MUST surface
conflicts rather than silently choosing by file enumeration order.
12.7. 12.7. Audit Log Integrity and Privacy
Receipts may expose repository layout, instruction text, developer
identity, tool use, or security controls. Receipts SHOULD minimize
content and access, and retention MUST follow organizational privacy
policy. Hashes of short or predictable instructions can be guessed;
a digest is not confidentiality. Signed logs protect against some
later changes but do not prove that the host captured every action or
that a compromised host enforced its recorded decision. A deployment
MUST document the logger's trust boundary, signing keys, retention,
and known omission paths.
12.8. 12.8. Denial of Service and Degraded Operation
Adversarial policies may contain excessive rules, huge glob sets,
deep structures, or expensive patterns. Parsers and resolvers MUST
bound file size, rule count, nesting, pattern length, and total
resolution time. A host MUST provide an operator-visible failure
state rather than silently truncating policy. An implementation MAY
disable the agent session when required organization policy cannot be
loaded.
12.9. 12.9. Interoperability Is Not Authorization
The presence of a policy file, a valid media type, or a conformance
label does not grant a person or agent authority to access a
repository, disclose data, or execute code. Authorization remains a
deployment responsibility. ACIP standardizes how sources are
represented, resolved, and reported; it does not establish an
identity system or authenticate a policy author by itself.
13. 13. IANA Considerations
This document requests registration of a media type and three
registries. These are proposals pending IETF review and IANA
approval; this document does not claim that the assignments already
exist. IANA is asked to perform the following actions.
Agarwal Expires 15 April 2027 [Page 20]
Internet-Draft ACIP October 2026
13.1. 13.1. Media Type Registration
IANA is asked to register the following media type in the Media Types
registry, using the +yaml structured syntax suffix already registered
by [RFC9512] and the procedures in [RFC6838].
* *Type name:* application
* *Subtype name:* agent-context+yaml
* *Required parameters:* N/A
* *Optional parameters:* N/A
* *Encoding considerations:* Binary. ACIP file content MUST be
UTF-8 encoded as specified in Section 5.2.
* *Security considerations:* See Section 12.
* *Interoperability considerations:* See Sections 5-7.
Implementations MUST follow the YAML subset and path-matching
semantics defined here.
* *Published specification:* This document, Sections 5-9.
* *Applications that use this media type:* IDEs, editors, command-
line coding agents, hosted development environments, and policy
adapters.
* *Fragment identifier considerations:* No fragment identifier
syntax is defined for this media type.
* *Additional information:* The preferred file extension is .agent-
context.yaml. The format is a single YAML 1.2 document. Intended
for local or authenticated policy exchange; not a web-origin
access policy.
* *Deprecated alias names:* N/A
* *Magic number(s):* N/A
* *File extension(s):* yaml
* *Macintosh file type code(s):* N/A
* *Person and email address to contact for further information:* To
be completed by the authors before submission.
Agarwal Expires 15 April 2027 [Page 21]
Internet-Draft ACIP October 2026
* *Intended usage:* LIMITED
* *Restrictions on usage:* Implementations MUST follow the trust and
security requirements in Section 12. Media type registration does
not imply policy authority.
* *Author:* To be completed by the authors before submission.
* *Change controller:* IETF
* *Provisional registration:* No
13.2. 13.2. Agent Policy Classes Registry
IANA is asked to create the *Agent Policy Classes* registry. The
registry defines the class values used by ACIP. Registration policy
is Specification Required as defined in [RFC8126]. A designated
expert MUST verify that a proposed class has an unambiguous meaning,
does not imply security enforcement through prose alone, and can be
represented in the resolution algorithm.
The registration template is:
* *Class token:* lowercase ASCII token, 1-32 characters.
* *Description:* concise definition of the class.
* *Resolution semantics:* precedence and conflict behavior.
* *Enforcement semantics:* host behavior, or the literal value none.
* *Security considerations:* class-specific risks and mitigations.
* *Reference:* stable public specification.
* *Change controller:* person or organization.
Initial registrations:
Agarwal Expires 15 April 2027 [Page 22]
Internet-Draft ACIP October 2026
+============+=============+==============+===============+=========+
| Class | Description | Resolution | Enforcement |Reference|
| token | | semantics | semantics | |
+============+=============+==============+===============+=========+
| constraint | Structured | Cumulative; | Host-enforced |This |
| | operation | deny wins | controls only |document,|
| | boundary | | |Sections |
| | | | |7-8 |
+------------+-------------+--------------+---------------+---------+
| directive | Required | Higher | None |This |
| | textual | source | |document,|
| | guidance | authority | |Sections |
| | | wins per | |7-8 |
| | | key | | |
+------------+-------------+--------------+---------------+---------+
| preference | Optional | Lower than | None |This |
| | textual | a directive | |document,|
| | guidance | at the same | |Sections |
| | | authority | |7-8 |
+------------+-------------+--------------+---------------+---------+
Table 1
13.3. 13.3. Agent Policy Controls Registry
IANA is asked to create the *Agent Policy Controls* registry.
Registration policy is Specification Required [RFC8126]. A
designated expert MUST review operational semantics, default
behavior, conflict behavior, and security considerations. A control
that cannot be evaluated before the operation reaches its target MUST
NOT be registered as an enforceable control.
The registration template is:
* *Control token:* lowercase ASCII token, 1-48 characters.
* *Description:* concise purpose.
* *Required parameters:* names, types, and limits.
* *Evaluation point:* the host boundary where the control is
applied.
* *Failure behavior:* required behavior on missing or invalid data.
* *Security considerations:* control-specific risks and mitigations.
* *Reference:* stable public specification.
Agarwal Expires 15 April 2027 [Page 23]
Internet-Draft ACIP October 2026
* *Change controller:* person or organization.
Initial registrations:
+=========+=============+==========+==========+===========+=========+
|Control |Description |Required |Evaluation|Failure |Reference|
|token | |parameters|point |behavior | |
+=========+=============+==========+==========+===========+=========+
|deny- |Prevents an |operation;|Before |Deny if |This |
|operation|operation |optional |tool |unsupported|document,|
| |from |paths glob|invocation|or |Sections |
| |reaching a |sequence | |malformed |7-8 |
| |tool | | | | |
+---------+-------------+----------+----------+-----------+---------+
|require- |Requires |operation |Before |Pause; do |This |
|approval |host- | |tool |not execute|document,|
| |mediated | |invocation|without |Sections |
| |human | | |approval |7-8 |
| |approval for | | | | |
| |an operation | | | | |
+---------+-------------+----------+----------+-----------+---------+
Table 2
13.4. 13.4. Agent Policy Operations Registry
IANA is asked to create the *Agent Policy Operations* registry.
Registration policy is Specification Required [RFC8126]. An
operation name identifies a host-mediated action category, not a
vendor tool name.
The registration template is:
* *Operation token:* lowercase ASCII token, 1-48 characters.
* *Description:* action category and target semantics.
* *Applicable controls:* controls that may reference the operation.
* *Security considerations:* operation-specific risks.
* *Reference:* stable public specification.
* *Change controller:* person or organization.
Initial registrations:
Agarwal Expires 15 April 2027 [Page 24]
Internet-Draft ACIP October 2026
+=================+==================+==================+===========+
| Operation token | Description | Applicable | Reference |
| | | controls | |
+=================+==================+==================+===========+
| file.read | Read | deny-operation, | This |
| | workspace | require-approval | document, |
| | file content | | Section 8 |
+-----------------+------------------+------------------+-----------+
| file.write | Create or | deny-operation, | This |
| | modify | require-approval | document, |
| | workspace | | Section 8 |
| | file content | | |
+-----------------+------------------+------------------+-----------+
| file.delete | Remove | deny-operation, | This |
| | workspace | require-approval | document, |
| | file content | | Section 8 |
+-----------------+------------------+------------------+-----------+
| process.exec | Start a | deny-operation, | This |
| | local or | require-approval | document, |
| | remote | | Section 8 |
| | process | | |
+-----------------+------------------+------------------+-----------+
| network.connect | Establish an | deny-operation, | This |
| | outbound | require-approval | document, |
| | network | | Section 8 |
| | connection | | |
+-----------------+------------------+------------------+-----------+
Table 3
14. References
14.1. Normative References
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC9512] Polli, R., Wilde, E., and E. Aro, "YAML Media Type",
RFC 9512, DOI 10.17487/RFC9512, February 2024,
<https://www.rfc-editor.org/info/rfc9512>.
Agarwal Expires 15 April 2027 [Page 25]
Internet-Draft ACIP October 2026
[YAML] YAML Language Development Team, "YAML Ain't Markup
Language Version 1.2.2", 1 October 2021,
<https://yaml.org/spec/1.2.2/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
14.2. Informative References
[AGENTSKILLS]
Agent Skills Project, "Agent Skills Specification", 12
October 2026, <https://agentskills.io/specification>.
[AGENTSMD] AGENTS.md Project, "AGENTS.md", 12 October 2026,
<https://agents.md/>.
[AIDER] Aider, "Specifying Coding Conventions", 12 October 2026,
<https://aider.chat/docs/usage/conventions.html>.
[ACP] Agent Client Protocol Project, "Agent Client Protocol", 12
October 2026,
<https://agentclientprotocol.com/protocol/overview>.
[CLAUDE] Anthropic, "How Claude Remembers Your Project", 12 October
2026, <https://code.claude.com/docs/en/memory>.
[CLINES] Cline, "Rules", 12 October 2026,
<https://docs.cline.bot/features/cline-rules>.
[COPILOT] GitHub, "Adding Repository Custom Instructions for GitHub
Copilot", 12 October 2026,
<https://docs.github.com/en/copilot/customizing-copilot/
adding-repository-custom-instructions-for-github-copilot>.
[CURSOR] Cursor, "Rules", 12 October 2026,
<https://cursor.com/docs/context/rules>.
[ECMA430] Ecma International, "Natural Language Interaction Protocol
(NLIP)", December 2025, <https://ecma-international.org/
publications-and-standards/standards/ecma-430/>.
Agarwal Expires 15 April 2027 [Page 26]
Internet-Draft ACIP October 2026
[ECMA431] Ecma International, "Binding of NLIP over HTTP/HTTPS",
December 2025, <https://ecma-international.org/
publications-and-standards/standards/ecma-431/>.
[ECMA432] Ecma International, "Binding of NLIP over WebSocket",
December 2025, <https://ecma-international.org/
publications-and-standards/standards/ecma-432/>.
[GEMINI] Google, "Agent Skills", 12 October 2026,
<https://geminicli.com/docs/cli/skills/>.
[IETFNEW] IETF, "Bringing New Work to the IETF", 12 October 2026,
<https://www.ietf.org/process/new-work/>.
[IETFAGENTS]
Nelson, R., "Agent Delegation Receipts", Work in Progress,
Internet-Draft, draft-nelson-agent-delegation-receipts-12,
October 2026, <https://datatracker.ietf.org/doc/draft-
nelson-agent-delegation-receipts/>.
[IETFMOQT] Jennings, C., "Model Context Protocol and Agent Skills
over Media over QUIC Transport", Work in Progress,
Internet-Draft, draft-jennings-agentproto-mcp-over-moqt-
00, July 2026, <https://datatracker.ietf.org/doc/draft-
jennings-agentproto-mcp-over-moqt/>.
[IETFROBOTS]
Dutta, S., "AGENTS.TXT: Strict Policy File for Automated
Clients", Work in Progress, Internet-Draft, draft-srijal-
agents-policy-00, October 2025,
<https://datatracker.ietf.org/doc/draft-srijal-agents-
policy/>.
[JUNIE] JetBrains, "Guidelines and Memory", 8 October 2026,
<https://junie.jetbrains.com/docs/guidelines-and-
memory.html>.
[LLMS] Howard, J., "The /llms.txt File", 10 August 2026,
<https://llmstxt.org/>.
[MCP] Model Context Protocol Project, "Model Context Protocol
Specification, 2025-11-25", 25 November 2025,
<https://modelcontextprotocol.io/
specification/2025-11-25>.
Agarwal Expires 15 April 2027 [Page 27]
Internet-Draft ACIP October 2026
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) Files", RFC 4180,
DOI 10.17487/RFC4180, October 2005,
<https://www.rfc-editor.org/info/rfc4180>.
[RFC9116] Foudil, E. and Y. Shafranovich, "A File Format to Aid in
Security Vulnerability Disclosure", RFC 9116,
DOI 10.17487/RFC9116, April 2022,
<https://www.rfc-editor.org/info/rfc9116>.
[RFC9920] Hoffman, P. and A. Rossi, "RFC Editor Model (Version 3)",
RFC 9920, DOI 10.17487/RFC9920, February 2026,
<https://www.rfc-editor.org/info/rfc9920>.
[WINDSURF] Cognition, "Memories and Rules", 12 October 2026,
<https://docs.devin.ai/desktop/cascade/memories>.
Appendix A. Rationale and Anticipated Objections
A.1. 14.1. "AGENTS.md Already Solves Portability"
AGENTS.md is a valuable cross-tool Markdown convention and this
specification preserves it. Markdown alone does not identify source
authority, distinguish preferences from enforceable controls, provide
portable file globs, or produce a resolution receipt. ACIP adds
those semantics without requiring projects to discard existing
AGENTS.md content.
A.2. 14.2. "This Is Prompt Engineering, Not a Standard"
The directive layer is prompt context, and ACIP explicitly does not
claim to make prose enforceable. The interoperable engineering
surface is the structured source model, deterministic precedence and
scope resolver, host-enforced controls, adapter loss reporting, and
audit receipt. These are testable behaviors across independent
implementations. A host that only injects text conforms to a weaker
profile and cannot claim security enforcement.
A.3. 14.3. "One More File Adds More Staleness"
The canonical file is intended to replace duplicated authoring
sources, not to coexist as a second authority. Vendor files are
generated projections and must be marked as such. A project can
adopt ACIP incrementally while retaining AGENTS.md and SKILL.md as
compatibility inputs; CI can detect drift in generated outputs. The
migration cost is real, but it is bounded and one-time per target
adapter rather than recurring authoring for every rule.
Agarwal Expires 15 April 2027 [Page 28]
Internet-Draft ACIP October 2026
A.4. 14.4. "A Vendor Will Ignore It Anyway"
Correct. A data format cannot force an unmodified agent to read or
honor it. The Adapter profile provides a useful bridge today by
rendering native files or injecting ordered context at launch. Only
native host support or a wrapper that mediates actions can provide
full resolution, enforcement, and audit conformance. ACIP makes
those limits visible rather than promising universal compatibility by
filename alone.
A.5. 14.5. "IETF Is Only for Wire Protocols"
IETF work includes protocol and data formats, registry procedures,
operational guidance, and informational documents. RFC 4180
documents a common data format and registers a media type; RFC 9116
defines the security.txt file format and a field registry, both as
Informational RFCs. RFC 9920 is a non-protocol RFC defining RFC-
series policy. These are precedents for an RFC documenting a format
or policy, not evidence that every IDE-specific format belongs in the
IETF [RFC4180] [RFC9116] [RFC9920].
A.6. 14.6. "Why Not Just Standardize MCP or NLIP?"
MCP standardizes context and tool integration; ACP standardizes the
editor to agent session protocol; ECMA NLIP standardizes natural-
language interaction. ACIP addresses a different layer: resolving
local and managed instruction sources before an agent action. ACIP
can be carried by MCP or ACP, but neither transport is required to
read a repository file or resolve organization and user
configuration.
A.7. 14.7. "Precedence Cannot Resolve Natural-Language Contradictions"
No general text algorithm can determine whether two arbitrary
paragraphs conflict. ACIP therefore requires authors to assign
stable keys to directives and preferences that are alternatives,
defines source and scope ordering for those keys, and surfaces equal-
rank collisions. Constraints are structured and enforced
independently of prose. This makes the tractable conflict classes
deterministic and exposes the remainder instead of silently letting
the model arbitrate them.
Author's Address
Shubham Agarwal
Email: shubham8scholar@gmail.com
Agarwal Expires 15 April 2027 [Page 29]