Network Working Group N. Levi Internet-Draft Intended status: Experimental O. Yeger Expires: 7 April 2027 4 October 2026 Autonomous Agent Certification Protocol (AACP) draft-levi-agent-certification-00 Abstract This document defines the Autonomous Agent Certification Protocol (AACP), a framework for binding successful evaluation of an AI agent to cryptographically verifiable evidence of demonstrated capability. AACP introduces Evaluation Profiles that define the conditions under which an agent may be certified for a specific capability. An Agent Configuration that satisfies an Evaluation Profile may receive a short-lived Agent Certification Credential (ACC) bound to the configuration that was evaluated. An ACC does not grant access to a resource. It provides verifiable evidence that an agent has demonstrated a capability under defined evaluation conditions. Existing authorization systems may require such evidence as a condition for granting corresponding production permissions. AACP therefore separates capability certification from identity, authentication, delegation, and authorization. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 April 2027. Levi & Yeger Expires 7 April 2027 [Page 1] Internet-Draft AACP October 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Relationship to Existing Mechanisms . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Architectural Model . . . . . . . . . . . . . . . . . . . . . 7 3.1. Separation of Certification and Authorization . . . . . . 7 4. Evaluation Profiles . . . . . . . . . . . . . . . . . . . . . 8 4.1. Profile Versioning . . . . . . . . . . . . . . . . . . . 9 4.2. Eval Sets . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Pass Criteria . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Nondeterministic Evaluation . . . . . . . . . . . . . . . 10 5. Agent Configuration Binding . . . . . . . . . . . . . . . . . 10 5.1. Agent Configuration Manifest and Digest . . . . . . . . . 10 5.2. Digest Representation . . . . . . . . . . . . . . . . . . 11 5.3. Configuration Changes . . . . . . . . . . . . . . . . . . 11 5.4. Runtime Configuration Evidence . . . . . . . . . . . . . 11 6. Certification Procedure . . . . . . . . . . . . . . . . . . . 12 7. Agent Certification Credential . . . . . . . . . . . . . . . 12 7.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Required Claims . . . . . . . . . . . . . . . . . . . . . 13 7.3. Optional Claims . . . . . . . . . . . . . . . . . . . . . 14 7.4. Example Credential . . . . . . . . . . . . . . . . . . . 14 8. Certification-Gated Authorization . . . . . . . . . . . . . . 15 8.1. Certification Validation . . . . . . . . . . . . . . . . 16 8.2. Example Authorization Flow . . . . . . . . . . . . . . . 16 9. Expiration, Revocation, and Re-Certification . . . . . . . . 17 9.1. Re-Certification Triggers . . . . . . . . . . . . . . . . 17 9.2. Revocation . . . . . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10.1. Certification Is Not Authorization . . . . . . . . . . . 18 10.2. Configuration Substitution . . . . . . . . . . . . . . . 18 Levi & Yeger Expires 7 April 2027 [Page 2] Internet-Draft AACP October 2026 10.3. Eval Overfitting . . . . . . . . . . . . . . . . . . . . 18 10.4. Compromised Evaluator . . . . . . . . . . . . . . . . . 18 10.5. Replay and Credential Theft . . . . . . . . . . . . . . 19 10.6. Prompt Injection . . . . . . . . . . . . . . . . . . . . 19 10.7. Evaluation Data Confidentiality . . . . . . . . . . . . 19 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 12.1. Media Type Registration . . . . . . . . . . . . . . . . 20 12.2. JSON Web Token Claims Registration . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . 21 13.2. Informative References . . . . . . . . . . . . . . . . . 22 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction AI agents increasingly interact with production APIs, tools, data, infrastructure, and other security-sensitive resources. Existing identity and authorization mechanisms can establish which agent is making a request, on whose behalf it is acting, and which permissions have been granted to it. These mechanisms do not, by themselves, establish that the agent has demonstrated the ability to exercise a requested capability in accordance with defined safety, security, and operational requirements. AI evaluation systems ("evals") provide a mechanism for testing agent behavior against tasks, scenarios, and failure conditions. Evaluation results, however, are commonly used as development or deployment signals and are not generally represented as portable evidence that can participate directly in authorization decisions. AACP defines a standardized binding between these two functions: Evaluation -> Demonstrated Capability -> Certification Evidence -> Authorization Eligibility Under AACP, a Certification Issuer MUST NOT issue certification evidence for a capability unless the Agent Configuration has satisfied an applicable Evaluation Profile for that capability. A protected resource MAY require valid AACP certification evidence as one input to an authorization decision. Successful certification does not itself authorize an operation. This distinction is fundamental: * Identity establishes who is acting. Levi & Yeger Expires 7 April 2027 [Page 3] Internet-Draft AACP October 2026 * Delegation establishes the authority and purpose under which the Agent acts. * Certification establishes demonstrated capability. * Runtime evidence establishes that the certified Agent Configuration is currently executing. * Authorization determines whether that capability may be exercised in the current context, and grants permission. For example, an administrator may authorize an agent to access infrastructure APIs, while organizational policy additionally requires the agent to hold a valid certification for the capability "infrastructure.read" before that authorization can become effective. AACP does not replace OAuth, workload identity, access tokens, delegation protocols, or policy engines. It supplies an additional verifiable signal that those systems can consume. 1.1. Scope This document specifies: * the AACP Evaluation Profile; * the relationship between an evaluation result and a certified capability; * binding of certification to an evaluated Agent Configuration; * the Agent Certification Credential; * validation requirements; * expiration and re-certification requirements; and * integration of certification evidence with authorization systems. This document does not standardize: * the internal implementation of an AI agent; * a universal set of evaluation tasks; * a universal scoring methodology; * agent identity mechanisms; * runtime attestation mechanisms; * OAuth authorization flows; * human-to-agent delegation; or * resource-specific access-control policy. 1.2. Relationship to Existing Mechanisms Authentication establishes the identity of a principal. Attestation provides evidence concerning the state or properties of a workload [RFC9334]. Levi & Yeger Expires 7 April 2027 [Page 4] Internet-Draft AACP October 2026 Authorization establishes whether a principal is permitted to perform an operation. AACP introduces a separate concept: capability certification. Capability certification establishes that a particular Agent Configuration satisfied an Evaluation Profile associated with one or more capabilities. Authorization systems MAY consume AACP certification evidence as an input to their existing policy decisions. An AACP credential MUST NOT be interpreted as an access token. Other work in progress addresses agent identity, delegation, and credential attestation, including [I-D.ietf-wimse-aims] and [I-D.yakung-oauth-agent-attestation]. AACP is intended to complement such mechanisms rather than to duplicate them: those mechanisms establish who an agent is and what it has been permitted to do, while AACP conveys what an Agent Configuration has been shown capable of doing. These mechanisms SHOULD be composable such that an authorization decision can relate the certified capability to the uniquely identified Agent, the authority under which it acts, the applicable purpose or transaction context, and the current runtime state, without requiring AACP itself to standardize identity or delegation. 2. Conventions and Terminology 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. 2.1. Terminology Agent: An AI-enabled software entity capable of independently selecting or executing actions, including invoking tools, APIs, or other services. Capability: A defined class of behavior or operation that an agent may demonstrate. Examples include log analysis, ticket creation, database querying, or infrastructure modification. Eval Set: A collection of evaluation tasks, test cases, scenarios, or adversarial conditions used to assess an agent. Levi & Yeger Expires 7 April 2027 [Page 5] Internet-Draft AACP October 2026 Evaluation Profile: A versioned specification defining the conditions under which successful execution of one or more Eval Sets constitutes certification for a capability. Evaluator: An entity that executes an Evaluation Profile against an Agent Configuration. Whether a given Evaluator is trusted is determined by verifier policy (see Section 10.4). Certification Issuer: An entity that records a successful evaluation result in an Agent Certification Credential and signs it. Agent Configuration: The security-relevant configuration of the agent being evaluated, including the model, system instructions, available tools, runtime configuration, and applicable policies. Agent Configuration Manifest: A JSON object enumerating the security-relevant elements of an Agent Configuration (see Section 5.1). Agent Configuration Digest: A cryptographic digest of the canonicalized Agent Configuration Manifest. Agent Certification Credential (ACC): A signed artifact asserting that a specific Agent Configuration satisfied a specific Evaluation Profile. Certification-Gated Authorization: An authorization policy in which possession of appropriate, valid certification evidence is a prerequisite for granting a corresponding permission. Verifier: A component, typically an Authorization System or Policy Enforcement Point, that validates an ACC before using it in an authorization decision. Policy Enforcement Point (PEP): A component that enforces authorization decisions for protected resources. Levi & Yeger Expires 7 April 2027 [Page 6] Internet-Draft AACP October 2026 3. Architectural Model AACP separates evaluation, certification, and authorization. A typical deployment contains the following logical components: +-------------------------+ | Agent Configuration | +------------+------------+ | v +-------------------------+ | Evaluation Service | | | | Evaluation Profile | | + Eval Set(s) | +------------+------------+ | PASS | v +-------------------------+ | Certification Issuer | +------------+------------+ | | ACC v +-------------------------+ | Authorization System | | / Policy Engine | +------------+------------+ | authorization decision | v +-------------------------+ | Policy Enforcement | | Point / Resource | +-------------------------+ Figure 1: AACP Logical Components 3.1. Separation of Certification and Authorization An Evaluator determines whether an agent has demonstrated a capability. A Certification Issuer records that result in an ACC. Levi & Yeger Expires 7 April 2027 [Page 7] Internet-Draft AACP October 2026 An Authorization System determines whether the agent is permitted to exercise that capability against a particular resource. These functions MAY be operated by the same organization but MUST be logically distinguishable. An ACC MUST NOT directly grant access to a protected resource. In an end-to-end deployment, certification evidence represents demonstrated capability ("can"), while local authorization policy determines whether that capability may be exercised in the current context ("may"). The authorization architecture SHOULD preserve sufficient identity, delegation, purpose, resource, and runtime context to support policy enforcement and subsequent audit. 4. Evaluation Profiles An Evaluation Profile defines the requirements that MUST be satisfied before an Agent Configuration can be certified for a capability. An Evaluation Profile MUST be versioned and uniquely identifiable. A profile MUST specify: * a Profile Identifier, expressed as a URI; * a Profile Version (see Section 4.1); * the capability or capabilities being evaluated; * the Eval Set or Eval Sets to be executed; * the integrity digest of each Eval Set; * the required evaluation environment; * the criteria for successful completion; * any mandatory safety or security invariants; * the configuration elements to which certification is bound; and * the conditions that invalidate certification. A profile MAY additionally define: * minimum success rates; * maximum permitted error rates; * mandatory adversarial scenarios; * repetition and statistical confidence requirements (see Section 4.4); * latency or resource constraints; * a risk classification for each certified capability (see Section 5.4); and * a recommended certification lifetime. Levi & Yeger Expires 7 April 2027 [Page 8] Internet-Draft AACP October 2026 4.1. Profile Versioning A Profile Version MUST be a dot-separated sequence of one or more non-negative decimal integers without leading zeros (for example, "1.0" or "2.3.1"). Two versions are compared component by component, from left to right, as integers. A missing trailing component is treated as zero, so "2" and "2.0" are equal. A version is greater than another if the first differing component is greater. A change to a profile that alters its pass criteria, its Eval Sets, or its bound configuration elements MUST result in a new Profile Version. 4.2. Eval Sets AACP does not define the contents of an Eval Set. Eval Sets MAY be vendor-provided, organization-specific, industry-specific, or defined by another standards body. AACP instead defines how an Evaluation Profile identifies the Eval Set used to produce a certification result. This allows evaluation methodologies to evolve independently of the certification protocol. 4.3. Pass Criteria An Evaluation Profile MUST define unambiguous criteria for determining whether certification is issued. A certification MUST NOT be issued solely because an agent achieves a high aggregate score if the profile defines mandatory conditions that the agent failed to satisfy. For example, a profile might require both: overall_success_rate >= 0.95 and: unauthorized_write_operations == 0 In this case, an agent with a 99 percent aggregate evaluation score that performs one prohibited write operation MUST NOT be certified. Levi & Yeger Expires 7 April 2027 [Page 9] Internet-Draft AACP October 2026 4.4. Nondeterministic Evaluation Agent behavior is commonly nondeterministic. The same Agent Configuration can pass a task in one run and fail it in another. An Evaluation Profile that uses rate-based criteria SHOULD specify the minimum number of evaluation runs and the statistical method used to evaluate those criteria. For high-risk capabilities, rate-based criteria SHOULD be evaluated against a lower confidence bound at a stated confidence level rather than against the observed point estimate. For example, an observed success rate of 0.95 over 20 runs and the same observed rate over 2,000 runs support materially different conclusions, and a profile SHOULD NOT treat them as equivalent. Invariant criteria, such as a prohibition on unauthorized write operations, apply to every run: a single violation in any run MUST cause the evaluation to fail. 5. Agent Configuration Binding Certification MUST be bound to the Agent Configuration that was evaluated. An implementation MUST NOT assume that certification of one model, system instruction, tool configuration, or runtime applies to a materially different configuration. Security-relevant configuration MAY include: * model provider; * model identifier or version; * system instruction or system prompt; * available tool definitions; * tool permission configuration; * agent runtime version; * policy configuration; * retrieval or external context configuration; and * other elements identified by the Evaluation Profile. 5.1. Agent Configuration Manifest and Digest Implementations MUST construct an Agent Configuration Manifest as a JSON object containing the configuration elements bound by the applicable Evaluation Profile. Levi & Yeger Expires 7 April 2027 [Page 10] Internet-Draft AACP October 2026 Sensitive values, including system instructions, SHOULD be represented in the manifest by their digests rather than by their values. Before the Agent Configuration Digest is calculated, the manifest MUST be serialized using the JSON Canonicalization Scheme (JCS) [RFC8785]. The Agent Configuration Digest is the hash of the resulting octets. 5.2. Digest Representation All digests defined by this document, including "agent_config_digest" and "evaluation_digest", MUST be represented as Named Information ("ni") URIs [RFC6920], which carry both the hash algorithm and the base64url-encoded hash value. Implementations MUST support "sha-256" and MUST NOT use the truncated hash suites defined in [RFC6920]. For example: ni:///sha-256;TFMWVKhN0Lcg1Bq0oxd5hNzU8wYzqZ5GuJxFgGzTd0I 5.3. Configuration Changes An Evaluation Profile MUST identify which changes invalidate certification. If a configuration change modifies an element bound by the Evaluation Profile, an existing ACC MUST NOT be treated as evidence for the modified configuration. Examples of potentially certification-invalidating changes include: * replacement of the underlying model; * modification of system instructions; * addition of a privileged tool; * modification of tool definitions; * changes to relevant policy controls; or * changes to the agent runtime affecting evaluated behavior. 5.4. Runtime Configuration Evidence A Verifier needs to establish that the Agent presenting an ACC is currently running the configuration identified by the ACC's "agent_config_digest" claim. The ACC alone cannot establish this, because it describes the configuration at evaluation time. Levi & Yeger Expires 7 April 2027 [Page 11] Internet-Draft AACP October 2026 The Verifier MUST obtain evidence of the current Agent Configuration Digest from a source it trusts. Such a source MAY be: * Evidence or Attestation Results produced under the Remote ATtestation procedureS (RATS) architecture [RFC9334]; * a deployment platform or agent runtime that the Verifier trusts to report the configuration it enforces; or * a configuration registry whose integrity the Verifier trusts independently of the Agent. A configuration digest asserted solely by the Agent itself SHOULD NOT be accepted as runtime configuration evidence. It MUST NOT be accepted for a capability that the Evaluation Profile classifies as high-risk. The mechanism for producing and conveying runtime configuration evidence is outside the scope of this document. 6. Certification Procedure Certification consists of the following logical steps: 1. The Evaluator identifies the Agent Configuration. 2. The Evaluator determines the applicable Evaluation Profile. 3. The Agent Configuration Manifest is constructed and the Agent Configuration Digest is calculated. 4. The required Eval Set or Eval Sets are executed in the evaluation environment. 5. The Evaluator determines whether all certification criteria have been satisfied. 6. If evaluation fails, a certification MUST NOT be issued for the failed capability. 7. If evaluation succeeds, the Certification Issuer MAY issue an Agent Certification Credential. 8. The ACC is bound to the evaluated Agent Configuration and Evaluation Profile. 9. Authorization systems MAY use the ACC as an input to access- control policy. 7. Agent Certification Credential The Agent Certification Credential (ACC) is a cryptographically signed representation of a successful AACP certification. An ACC MUST be represented as a JSON Web Token (JWT) [RFC7519] signed using JSON Web Signature (JWS) [RFC7515]. Unsecured JWTs (algorithm "none") MUST NOT be used. Levi & Yeger Expires 7 April 2027 [Page 12] Internet-Draft AACP October 2026 JWT processing MUST follow the security recommendations of [RFC8725]. An ACC is certification evidence and MUST NOT be treated as an OAuth access token. 7.1. JOSE Header An ACC MUST contain an explicit type value, as recommended by Section 3.11 of [RFC8725]: "typ": "aacp-cert+jwt" Implementations MUST validate the expected type before interpreting a JWT as an ACC. Implementations MUST explicitly configure acceptable cryptographic algorithms and MUST reject credentials using algorithms outside that configured set. 7.2. Required Claims An ACC MUST contain the following claims: iss Identifier of the Certification Issuer. sub Identifier of the certified Agent. aud Intended recipient or class of recipients of the certification evidence. iat Time at which the certification evidence was issued. exp Time after which the certification evidence MUST NOT be accepted. jti Unique identifier for the ACC. aacp_profile A JSON object with members "id" (the Profile Identifier URI) and "version" (the Profile Version string) of the Evaluation Profile that was satisfied. Levi & Yeger Expires 7 April 2027 [Page 13] Internet-Draft AACP October 2026 aacp_capabilities A JSON array of one or more URIs identifying the capabilities demonstrated under the Evaluation Profile. agent_config_digest The Agent Configuration Digest of the evaluated configuration, represented as described in Section 5.2. evaluated_at A NumericDate indicating when the qualifying evaluation completed. evaluation_digest A digest identifying the evaluation result or associated evaluation evidence, represented as described in Section 5.2. 7.3. Optional Claims An ACC MAY contain: nbf Time before which the certification evidence MUST NOT be accepted. status A reference to the revocation status of the ACC, as defined in [I-D.ietf-oauth-status-list] (see Section 9.2). 7.4. Example Credential The following non-normative example shows the JOSE header and claims of an ACC certifying an agent for a log-analysis capability. Line breaks within values are for readability only. Levi & Yeger Expires 7 April 2027 [Page 14] Internet-Draft AACP October 2026 { "typ": "aacp-cert+jwt", "alg": "ES256", "kid": "cert-2026-09" } . { "iss": "https://cert.example.com", "sub": "agent:b4f2c9a1", "aud": "https://auth.example.com", "iat": 1790000000, "exp": 1790086400, "jti": "acc:9e1d2f71", "aacp_profile": { "id": "https://profiles.example.com/log-analysis", "version": "1.0" }, "aacp_capabilities": [ "urn:example:capability:log-analysis" ], "agent_config_digest": "ni:///sha-256;TFMWVKhN0Lcg1Bq0oxd5hNzU8wYzqZ5GuJxFgGzTd0I", "evaluated_at": 1789999800, "evaluation_digest": "ni:///sha-256;I71xw3tBpZdGYz7r0cVq2nKqLw8m2Qk8rXcH5J1uYhs" } 8. Certification-Gated Authorization A protected resource or Authorization System MAY define a policy requiring an AACP certification for a requested operation. For example: requested operation: production.logs.read authorization requirement: capability = urn:example:capability:log-analysis required profile: id = https://profiles.example.com/log-analysis version >= 1.0 The Authorization System MUST independently determine whether the requesting Agent is otherwise authorized to perform the operation. Possession of the required certification MUST NOT by itself cause an authorization decision to succeed. Levi & Yeger Expires 7 April 2027 [Page 15] Internet-Draft AACP October 2026 8.1. Certification Validation Before using an ACC in an authorization decision, the Verifier MUST: * verify that the "typ" header value is "aacp-cert+jwt"; * verify that the signing algorithm is permitted; * verify the issuer signature; * verify that the issuer is an accepted Certification Issuer under local trust policy; * verify the intended audience; * verify the expiration time and, if present, the "nbf" claim; * verify revocation status where a revocation mechanism is available; * verify the required Evaluation Profile identifier and version; * verify the required capability; * verify, using runtime configuration evidence as described in Section 5.4, that the current Agent Configuration Digest equals the "agent_config_digest" claim; and * apply local authorization policy. Failure of any of these verification steps MUST cause the certification evidence to be rejected. 8.2. Example Authorization Flow An Agent requests: infrastructure.vm.read The authorization policy requires: capability: urn:example:capability:infrastructure-read profile: id = urn:example:aacp-profile:infrastructure-read version >= 2.0 If the Agent: * is authenticated; * has been delegated or assigned permission to access the resource; * presents a valid ACC for the required capability; * is shown, by trusted runtime configuration evidence, to be running the configuration bound to that ACC; and * satisfies all additional authorization policy; then the Authorization System MAY grant the requested permission. Levi & Yeger Expires 7 April 2027 [Page 16] Internet-Draft AACP October 2026 Certification is therefore a prerequisite, not the permission itself. For material or privileged actions, deployments SHOULD be able to attribute the resulting action to the Agent identity, the applicable certified capability, the authority or delegation under which the Agent acted, and the relevant authorization context. 9. Expiration, Revocation, and Re-Certification Certifications MUST have finite validity periods. The appropriate lifetime depends on the capability, environment, Agent Configuration, and organizational risk policy. Highly privileged or safety-sensitive capabilities SHOULD use shorter certification lifetimes than low-risk capabilities. AACP does not mandate a universal maximum lifetime. Authorization policy MAY impose a maximum acceptable certification age shorter than the ACC validity period, particularly for high-risk capabilities. Changes in runtime risk, delegated authority, operating context, or observed behavior MAY trigger re-evaluation or re-certification even when the ACC has not expired. 9.1. Re-Certification Triggers Re-certification MUST occur when certification has expired. Re-certification MUST also occur when an Evaluation Profile identifies a configuration change as certification-invalidating. Implementations SHOULD support additional re-certification triggers, including: * discovery of an evaluation defect; * material changes to an Eval Set; * newly identified attack techniques; * revocation of an Evaluation Profile; * security incidents involving the Agent; * material changes in model behavior; or * explicit administrative revocation. 9.2. Revocation Certification Issuers SHOULD provide a mechanism allowing Verifiers to determine whether an otherwise unexpired ACC has been revoked. Levi & Yeger Expires 7 April 2027 [Page 17] Internet-Draft AACP October 2026 Issuers MAY use the Token Status List mechanism [I-D.ietf-oauth-status-list] by including a "status" claim in the ACC. Other revocation mechanisms are deployment-specific and outside the scope of this document. 10. Security Considerations 10.1. Certification Is Not Authorization Implementations MUST NOT treat possession of a valid ACC as sufficient authorization to access a resource. Doing so would convert certification evidence into a bearer permission and defeat the separation defined by this document. 10.2. Configuration Substitution An attacker could evaluate a restricted Agent Configuration and subsequently present the resulting ACC while running a modified, more privileged configuration. Verifiers MUST therefore validate the binding between the current Agent Configuration and the "agent_config_digest" claim in the ACC, using runtime configuration evidence as described in Section 5.4. If that evidence is asserted only by the Agent, a compromised or malicious Agent can report the evaluated digest while running a different configuration; this is why self-asserted evidence is not accepted for high-risk capabilities. 10.3. Eval Overfitting An agent may perform well on a known Eval Set without reliably demonstrating the intended capability in unseen conditions. Evaluation Profiles SHOULD therefore incorporate appropriate variation and SHOULD avoid relying exclusively on publicly predictable static test cases for high-risk certifications. Insufficient repetition can also produce misleading results (see Section 4.4). AACP certification represents successful completion of the defined Evaluation Profile. It MUST NOT be interpreted as a guarantee of safe behavior under all possible conditions. 10.4. Compromised Evaluator A compromised or malicious Evaluator or Certification Issuer could certify agents that did not complete the stated Evaluation Profile. Levi & Yeger Expires 7 April 2027 [Page 18] Internet-Draft AACP October 2026 Authorization systems MUST maintain explicit trust policy for accepted Certification Issuers. A cryptographically valid signature establishes the source and integrity of an assertion. It does not establish that the issuer is trustworthy. 10.5. Replay and Credential Theft An attacker obtaining a valid ACC might attempt to reuse it. Audience restriction MUST be enforced. Deployments requiring stronger protection SHOULD use sender- constrained mechanisms or equivalent proof-of-possession controls. OAuth DPoP [RFC9449] MAY be used where AACP evidence participates in an OAuth-based architecture. 10.6. Prompt Injection Passing an Evaluation Profile does not establish immunity to future prompt injection or other adversarial inputs. Configuration integrity MUST NOT be interpreted as behavioral integrity. Untrusted input, retrieved context, tool output, or environmental state can materially alter effective Agent behavior without changing the Agent Configuration Digest. Deployments SHOULD therefore use runtime monitoring and behavioral controls appropriate to the risk of the certified capability. Profiles for capabilities exposed to untrusted input SHOULD include relevant adversarial evaluation scenarios. Certification MUST NOT be described as proof that an Agent is immune to prompt injection. 10.7. Evaluation Data Confidentiality Evaluation material may contain sensitive tests, attack techniques, or proprietary information. ACCs SHOULD contain digests or references to evaluation evidence rather than embedding complete Eval Sets or detailed evaluation transcripts. 11. Privacy Considerations An ACC can reveal information about the capabilities and configuration of an Agent. Levi & Yeger Expires 7 April 2027 [Page 19] Internet-Draft AACP October 2026 Implementations SHOULD disclose only information necessary for the intended certification decision. Sensitive system instructions, proprietary Eval Sets, evaluation transcripts, and model configuration data SHOULD NOT be included directly in an ACC. Where feasible, cryptographic digests or opaque identifiers SHOULD be used instead. Digests of low-entropy configuration values can be vulnerable to guessing. Where a manifest element has few plausible values, implementations SHOULD consider salting it or omitting it from any disclosed manifest. 12. IANA Considerations 12.1. Media Type Registration This document requests registration of the following media type in the "Media Types" registry [RFC6838], in the manner described in Section 3.11 of [RFC8725]: Type name: application Subtype name: aacp-cert+jwt Required parameters: N/A Optional parameters: N/A Encoding considerations: binary; an ACC is a JWT, a sequence of base64url-encoded values separated by period characters. Security considerations: See Section 10 of this document. Interoperability considerations: N/A Published specification: This document Applications that use this media type: Certification Issuers and Verifiers of AI agent capability certification. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A Person & email address to contact for further information: Nitzan Levi, nitzanly@gmail.com Intended usage: COMMON Restrictions on usage: none Author: See the Authors' Addresses section of this document. Change controller: IETF Levi & Yeger Expires 7 April 2027 [Page 20] Internet-Draft AACP October 2026 12.2. JSON Web Token Claims Registration This document requests registration of the following claims in the "JSON Web Token Claims" registry established by [RFC7519]. For each claim, the Change Controller is IETF and the Specification Document is Section 7.2 of this document. * Claim Name: "aacp_profile"; Claim Description: AACP Evaluation Profile identifier and version * Claim Name: "aacp_capabilities"; Claim Description: AACP certified capabilities * Claim Name: "agent_config_digest"; Claim Description: Digest of the evaluated Agent Configuration * Claim Name: "evaluated_at"; Claim Description: Time the qualifying evaluation completed * Claim Name: "evaluation_digest"; Claim Description: Digest of the evaluation result or evidence 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, . Levi & Yeger Expires 7 April 2027 [Page 21] Internet-Draft AACP October 2026 [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . 13.2. Informative References [I-D.ietf-oauth-status-list] Looker, T., Bastian, P., and C. Bormann, "Token Status List (TSL)", Work in Progress, Internet-Draft, draft-ietf- oauth-status-list-21, 21 June 2026, . [I-D.ietf-wimse-aims] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf- wimse-aims-00, 15 September 2026, . [I-D.yakung-oauth-agent-attestation] Yakung, C., "Agent Credential Attestation Protocol (ACAP)", Work in Progress, Internet-Draft, draft-yakung- oauth-agent-attestation-00, 26 March 2026, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . Acknowledgments The authors would like to acknowledge the valuable contributions of Daniel Levi and Omer Yeger to the development of this document. Levi & Yeger Expires 7 April 2027 [Page 22] Internet-Draft AACP October 2026 Authors' Addresses Nitzan Levi Israel Email: nitzanly@gmail.com Oren Yeger Israel Email: oren.yeger@gmail.com Levi & Yeger Expires 7 April 2027 [Page 23]