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: ~~~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." ~~~ 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, . [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, . [RFC9512] Polli, R., Wilde, E., and E. Aro, "YAML Media Type", RFC 9512, DOI 10.17487/RFC9512, February 2024, . 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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 14.2. Informative References [AGENTSKILLS] Agent Skills Project, "Agent Skills Specification", 12 October 2026, . [AGENTSMD] AGENTS.md Project, "AGENTS.md", 12 October 2026, . [AIDER] Aider, "Specifying Coding Conventions", 12 October 2026, . [ACP] Agent Client Protocol Project, "Agent Client Protocol", 12 October 2026, . [CLAUDE] Anthropic, "How Claude Remembers Your Project", 12 October 2026, . [CLINES] Cline, "Rules", 12 October 2026, . [COPILOT] GitHub, "Adding Repository Custom Instructions for GitHub Copilot", 12 October 2026, . [CURSOR] Cursor, "Rules", 12 October 2026, . [ECMA430] Ecma International, "Natural Language Interaction Protocol (NLIP)", December 2025, . Agarwal Expires 15 April 2027 [Page 26] Internet-Draft ACIP October 2026 [ECMA431] Ecma International, "Binding of NLIP over HTTP/HTTPS", December 2025, . [ECMA432] Ecma International, "Binding of NLIP over WebSocket", December 2025, . [GEMINI] Google, "Agent Skills", 12 October 2026, . [IETFNEW] IETF, "Bringing New Work to the IETF", 12 October 2026, . [IETFAGENTS] Nelson, R., "Agent Delegation Receipts", Work in Progress, Internet-Draft, draft-nelson-agent-delegation-receipts-12, October 2026, . [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, . [IETFROBOTS] Dutta, S., "AGENTS.TXT: Strict Policy File for Automated Clients", Work in Progress, Internet-Draft, draft-srijal- agents-policy-00, October 2025, . [JUNIE] JetBrains, "Guidelines and Memory", 8 October 2026, . [LLMS] Howard, J., "The /llms.txt File", 10 August 2026, . [MCP] Model Context Protocol Project, "Model Context Protocol Specification, 2025-11-25", 25 November 2025, . 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, . [RFC9116] Foudil, E. and Y. Shafranovich, "A File Format to Aid in Security Vulnerability Disclosure", RFC 9116, DOI 10.17487/RFC9116, April 2022, . [RFC9920] Hoffman, P. and A. Rossi, "RFC Editor Model (Version 3)", RFC 9920, DOI 10.17487/RFC9920, February 2026, . [WINDSURF] Cognition, "Memories and Rules", 12 October 2026, . 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]