Autonomous Agent Certification Protocol (AACP)
draft-levi-agent-certification-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Nitzan Levi , Oren Yeger | ||
| Last updated | 2026-10-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-levi-agent-certification-00
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,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc6920>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/info/rfc8725>.
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,
<https://www.rfc-editor.org/info/rfc8785>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
status-list-21>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
aims-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-yakung-oauth-
agent-attestation-00>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[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, <https://www.rfc-editor.org/info/rfc9334>.
[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, <https://www.rfc-editor.org/info/rfc9449>.
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]