]>

shubham8scholar@gmail.com

AI agents coding agents policy instructions 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.

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. 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. Relationship to Adjacent Work The Model Context Protocol (MCP) defines an integration protocol for context, resources, prompts, and tools between hosts, clients, and servers . The Agent Client Protocol (ACP) standardizes editor-to-agent communication . 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 . 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 . AGENTS.md is a broadly adopted, plain-Markdown convention. It does not define structured constraint types or a universal precedence algorithm . 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 . Aider loads convention files by configuration, while Junie and current Windsurf/Devin documentation support AGENTS.md alongside product-specific rules . The llms.txt proposal is a website documentation-navigation convention, not a coding-agent policy format . An expired IETF AGENTS.TXT draft concerns crawler access policy, not IDE coding-agent instructions . 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 . 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 . Internet-Drafts are work in progress and are not endorsed standards .

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 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. 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. 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. Policy Sources and Trust Each policy source has a provenance level assigned by the host: Organization: Policy delivered by a host's administrator-managed policy channel or an equivalent operating-system-managed location. Project: Policy checked into the repository or supplied by the repository's trusted workspace configuration. Task: Instructions supplied for the current request by the human initiating that task. User: Persistent preferences configured by the individual user. 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. 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. Policy Document Format

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

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. 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. 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. Scope and Matching

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. 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. 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. 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. 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. 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. 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. 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. Filter by scope. Retain only rules whose path scope matches at least one operation target, or whose scope is "**" when no path is known. 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. 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. 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. 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. 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. Rule Classes and Host Enforcement

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. Initial Controls The initial Agent Policy Controls registry contains: 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. 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. Audit and Resolution Receipts

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; 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. 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. 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. 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. Backward Compatibility and Migration

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

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.

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

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. 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. Security Considerations

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. 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 rule. If an operation bypasses the host, ACIP cannot protect it.

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

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

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 and the procedures in . 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. 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. 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 . 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: Class token Description Resolution semantics Enforcement semantics Reference constraint Structured operation boundary Cumulative; deny wins Host-enforced controls only This document, Sections 7-8 directive Required textual guidance Higher source authority wins per key None This document, Sections 7-8 preference Optional textual guidance Lower than a directive at the same authority None This document, Sections 7-8

13.3. Agent Policy Controls Registry IANA is asked to create the Agent Policy Controls registry. Registration policy is Specification Required . 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. Change controller: person or organization. Initial registrations: Control token Description Required parameters Evaluation point Failure behavior Reference deny-operation Prevents an operation from reaching a tool operation; optional paths glob sequence Before tool invocation Deny if unsupported or malformed This document, Sections 7-8 require-approval Requires host-mediated human approval for an operation operation Before tool invocation Pause; do not execute without approval This document, Sections 7-8

13.4. Agent Policy Operations Registry IANA is asked to create the Agent Policy Operations registry. Registration policy is Specification Required . 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: Operation token Description Applicable controls Reference file.read Read workspace file content deny-operation, require-approval This document, Section 8 file.write Create or modify workspace file content deny-operation, require-approval This document, Section 8 file.delete Remove workspace file content deny-operation, require-approval This document, Section 8 process.exec Start a local or remote process deny-operation, require-approval This document, Section 8 network.connect Establish an outbound network connection deny-operation, require-approval This document, Section 8

&RFC6838; &RFC8126; &RFC9512; YAML Language Development Team &RFC2119; &RFC8174; Agent Skills Project AGENTS.md Project Aider Agent Client Protocol Project Anthropic Cline GitHub Cursor Ecma International Ecma International Ecma International Google IETF JetBrains Model Context Protocol Project &RFC4180; &RFC9116; &RFC9920; Cognition

Rationale and Anticipated Objections

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.

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.

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.

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.

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 .

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.

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.