Autonomous Agent Certification Protocol (AACP)

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

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

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

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

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

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

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

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

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

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

{
  "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.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.¶

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

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

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

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¶

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¶