]>

Israel nitzanly@gmail.com

Israel oren.yeger@gmail.com

Security AI agents certification evaluation JWT authorization 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.

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

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.

Relationship to Existing Mechanisms Authentication establishes the identity of a principal. Attestation provides evidence concerning the state or properties of a workload . 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 and . 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.

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 when, and only when, they appear in all capitals, as shown here.

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

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

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.

Architectural Model AACP separates evaluation, certification, and authorization. A typical deployment contains the following logical components:

AACP Logical Components

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.

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 );
• 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 );
• latency or resource constraints;
• a risk classification for each certified capability (see ); and
• a recommended certification lifetime.

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.

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.

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: = 0.95 ]]> and: In this case, an agent with a 99 percent aggregate evaluation score that performs one prohibited write operation MUST NOT be certified.

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.

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.

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) . The Agent Configuration Digest is the hash of the resulting octets.

Digest Representation All digests defined by this document, including "agent_config_digest" and "evaluation_digest", MUST be represented as Named Information ("ni") URIs , 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 . For example:

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.

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

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.

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) signed using JSON Web Signature (JWS) . Unsecured JWTs (algorithm "none") MUST NOT be used. JWT processing MUST follow the security recommendations of . An ACC is certification evidence and MUST NOT be treated as an OAuth access token.

JOSE Header An ACC MUST contain an explicit type value, as recommended by : 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.

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 .

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 .

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 (see ).

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.

Certification-Gated Authorization A protected resource or Authorization System MAY define a policy requiring an AACP certification for a requested operation. For example: = 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.

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

Example Authorization Flow An Agent requests: The authorization policy requires: = 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.

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.

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.

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 by including a "status" claim in the ACC. Other revocation mechanisms are deployment-specific and outside the scope of this document.

Security Considerations

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.

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

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

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.

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 MAY be used where AACP evidence participates in an OAuth-based architecture.

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.

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.

Privacy Considerations An ACC can reveal information about the capabilities and configuration of an Agent. 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.

IANA Considerations

Media Type Registration This document requests registration of the following media type in the "Media Types" registry , in the manner described in :

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

JSON Web Token Claims Registration This document requests registration of the following claims in the "JSON Web Token Claims" registry established by . For each claim, the Change Controller is IETF and the Specification Document is 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

References Normative References Informative References

Acknowledgments The authors would like to acknowledge the valuable contributions of Daniel Levi and Omer Yeger to the development of this document.