X.509 Certificate Profile for Autonomous AI Agent Identity
draft-sharif-x509-agent-identity-profile-03
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) | |
|---|---|---|---|
| Author | Raza Sharif | ||
| Last updated | 2026-07-31 | ||
| 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-sharif-x509-agent-identity-profile-03
Internet Engineering Task Force R. Sharif
Internet-Draft CyberSecAI Ltd
Intended status: Standards Track July 31, 2026
Expires: January 26, 2027
X.509 Certificate Profile for Autonomous AI Agent Identity
draft-sharif-x509-agent-identity-profile-03
Abstract
This document defines an X.509 certificate profile for identifying
autonomous AI agents. It specifies a new X.509v3 extension,
AgentIdentity, that encodes agent-specific metadata within a
standard X.509 certificate, including agent trust level,
operational capabilities, delegation constraints, owner attribution,
and revocation control endpoints.
The profile enables certificate authorities (CAs) to issue
interoperable agent identity certificates that any relying party
can parse, validate, and enforce, regardless of the issuing CA or
the platform that provisioned the agent.
The design builds on existing PKI infrastructure (RFC 5280), SPIFFE
Verifiable Identity Documents (SPIFFE SVIDs), and the MCPS
cryptographic signing layer (draft-sharif-mcps-secure-mcp). It
does not require changes to X.509v3 certificate parsing or to
existing CA issuance pipelines beyond supporting a new non-critical
extension.
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 January 26, 2027.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . 5
4. Agent Identity Extension . . . . . . . . . . . . . . . . . 6
4.1. Extension OID . . . . . . . . . . . . . . . . . . . . . 6
4.2. ASN.1 Structure . . . . . . . . . . . . . . . . . . . . 6
4.3. Field Definitions . . . . . . . . . . . . . . . . . . . 7
4.3.1. agentVersion . . . . . . . . . . . . . . . . . . . 7
4.3.2. trustLevel . . . . . . . . . . . . . . . . . . . . 7
4.3.3. capabilities . . . . . . . . . . . . . . . . . . . 8
4.3.4. ownerOrganization . . . . . . . . . . . . . . . . . 8
4.3.5. platformIdentifier . . . . . . . . . . . . . . . . 9
4.3.6. maxDelegationDepth . . . . . . . . . . . . . . . . 9
4.3.7. killSwitchURI . . . . . . . . . . . . . . . . . . . 9
4.3.8. agentClass . . . . . . . . . . . . . . . . . . . . 10
4.3.9. signingKeyHash . . . . . . . . . . . . . . . . . . 10
5. Certificate Profile . . . . . . . . . . . . . . . . . . . . 11
5.1. Subject Field . . . . . . . . . . . . . . . . . . . . . 11
5.2. Subject Alternative Name . . . . . . . . . . . . . . . 11
5.3. Key Usage . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Extended Key Usage . . . . . . . . . . . . . . . . . . 12
5.5. Basic Constraints . . . . . . . . . . . . . . . . . . . 12
5.6. Certificate Lifetime . . . . . . . . . . . . . . . . . 12
6. Trust Levels . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Level 0: Unknown . . . . . . . . . . . . . . . . . . . 13
6.2. Level 1: Registered . . . . . . . . . . . . . . . . . . 13
6.3. Level 2: Verified . . . . . . . . . . . . . . . . . . . 13
6.4. Level 3: Trusted . . . . . . . . . . . . . . . . . . . 14
6.5. Level 4: Critical . . . . . . . . . . . . . . . . . . . 14
7. Agent Classes . . . . . . . . . . . . . . . . . . . . . . . 15
8. Delegation Model . . . . . . . . . . . . . . . . . . . . . 16
8.1. Scope Attenuation . . . . . . . . . . . . . . . . . . . 16
8.2. Delegation Chain Validation . . . . . . . . . . . . . . 16
9. Revocation and Kill Switch . . . . . . . . . . . . . . . . 17
9.1. OCSP Integration . . . . . . . . . . . . . . . . . . . 17
9.2. Kill Switch Semantics . . . . . . . . . . . . . . . . . 17
9.3. Hardware Kill Switch . . . . . . . . . . . . . . . . . 18
10. Relationship to SPIFFE . . . . . . . . . . . . . . . . . . 18
11. Relationship to MCPS . . . . . . . . . . . . . . . . . . . 19
12. CA Issuance Procedures . . . . . . . . . . . . . . . . . . 19
12.1. Agent Identity Validation . . . . . . . . . . . . . . . 20
12.2. Capability Attestation . . . . . . . . . . . . . . . . 20
12.3. Certificate Transparency . . . . . . . . . . . . . . . 20
13. Relying Party Verification . . . . . . . . . . . . . . . . 21
14. Security Considerations . . . . . . . . . . . . . . . . . . 22
14.1. Trust Level Escalation . . . . . . . . . . . . . . . . 22
14.2. Capability Inflation . . . . . . . . . . . . . . . . . 22
14.3. Kill Switch Availability . . . . . . . . . . . . . . . 22
14.4. Delegation Depth Exhaustion . . . . . . . . . . . . . . 22
14.5. Agent Impersonation . . . . . . . . . . . . . . . . . . 23
14.6. Compromised Platform Keys . . . . . . . . . . . . . . . 23
14.7. Clock Skew and Certificate Lifetime . . . . . . . . . . 23
14.8. Cross-Domain Trust . . . . . . . . . . . . . . . . . . 23
15. Privacy Considerations . . . . . . . . . . . . . . . . . . 24
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24
16.1. OID Registration . . . . . . . . . . . . . . . . . . . 24
16.2. Agent Class Registry . . . . . . . . . . . . . . . . . 25
16.3. Extended Key Usage Registration . . . . . . . . . . . . 25
17. References . . . . . . . . . . . . . . . . . . . . . . . . 25
17.1. Normative References . . . . . . . . . . . . . . . . . 25
17.2. Informative References . . . . . . . . . . . . . . . . 26
Appendix A. Example Agent Certificate . . . . . . . . . . . . 27
Appendix B. ASN.1 Module . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction
Autonomous AI agents are being deployed at scale across enterprise
environments. These agents execute code, access databases, invoke
external services, make purchases, control physical devices, and
communicate with other agents. In 2026, 70% of enterprises report
having AI agents in production, yet only 21.9% treat agents as
independent, identity-bearing entities with their own access
controls.
The X.509 public key infrastructure has provided cryptographic
identity for websites (TLS server certificates), software (code
signing certificates), email (S/MIME certificates), devices (IoT
device certificates), and workloads (SPIFFE SVIDs) for decades.
However, no standard certificate profile exists for AI agents.
This document fills that gap by defining:
(a) A new X.509v3 extension, AgentIdentity, that carries
agent-specific metadata within a standard X.509 certificate.
(b) A certificate profile specifying how certificate authorities
issue agent identity certificates.
(c) A trust level taxonomy (L0 through L4) that enables graduated
authorization decisions based on the trust level encoded in
the certificate.
(d) A delegation model enabling parent agents to create child
agents with attenuated scope.
(e) A kill switch mechanism for immediate agent revocation,
including hardware-assisted human approval.
The profile is designed to be CA-agnostic. Any certificate
authority can issue agent identity certificates conforming to this
profile. The extension is non-critical, ensuring backward
compatibility with existing X.509v3 parsers.
This work is motivated by production incidents where AI agents
operated without verifiable identity, leading to unauthorized
actions, inability to attribute agent behavior for audit or legal
purposes, and absence of a revocation mechanism capable of
operating at machine speed.
2. 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.
Agent: An autonomous software entity that performs actions on
behalf of a principal (human user, organization, or another
agent) without continuous human supervision.
Agent Identity Certificate: An X.509v3 certificate containing
the AgentIdentity extension defined in this document.
Trust Level: An integer value (0 through 4) indicating the
degree of autonomous authority granted to an agent, encoded
in the AgentIdentity extension.
Capability: A named permission describing an action an agent
is authorized to perform, encoded as a UTF8String in the
AgentIdentity extension.
Kill Switch: A URI endpoint that, when invoked, triggers
immediate and irrevocable cessation of agent operations.
Delegation: The act of a parent agent creating a child agent
with a subset of the parent's capabilities and a trust level
not exceeding the parent's trust level.
Scope Attenuation: The principle that delegated authority can
only narrow, never broaden, relative to the delegating agent.
Platform: The software system responsible for agent lifecycle
management, certificate request generation, and trust level
enforcement.
Relying Party: Any entity that receives and validates an agent
identity certificate to make an authorization decision.
3. Problem Statement
AI agents in production environments face the following identity
and trust challenges:
(a) No Standard Identity Format: Agents are identified by
API keys, bearer tokens, or opaque identifiers that provide
no cryptographic binding between the agent and its actions.
These identifiers can be shared, replayed, or forged.
(b) No Graduated Authorization: Existing systems apply binary
allow/deny decisions. There is no standard mechanism to
express that an agent may read data but not make payments,
or that a payment requires human approval above a threshold.
(c) No Delegation Semantics: When an agent creates a sub-agent,
there is no standard way to express that the sub-agent's
authority is a strict subset of the parent's.
(d) No Interoperable Revocation: Agent revocation is
platform-specific. An agent revoked in one system may
continue to operate in another. There is no standard
revocation mechanism that works across platforms and CAs.
(e) No Audit Attribution: When an agent performs an action,
there is no cryptographically verifiable way to attribute
that action to a specific agent with a specific trust level
at a specific point in time.
(f) No CA Interoperability: Without a standard certificate
profile, each platform defines its own agent metadata
format. An agent certificate issued by CA-A cannot be
meaningfully parsed by a system expecting CA-B's format.
This document addresses all six challenges by defining a single,
interoperable certificate profile that any CA can issue and any
relying party can validate.
4. Agent Identity Extension
4.1. Extension OID
The AgentIdentity extension is identified by the following
object identifier, allocated under the CyberSecAI Private
Enterprise Number arc:
id-pe-agentIdentity OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
private(4) enterprise(1) cybersecai(66339) 1 }
The extension MUST be marked non-critical. This ensures that
X.509v3 implementations that do not recognize the extension
will still accept the certificate. Relying parties that
understand the extension MUST process it when present.
The CyberSecAI Private Enterprise Number 66339 was assigned by
IANA on 22 July 2026.
4.2. ASN.1 Structure
AgentIdentity ::= SEQUENCE {
agentVersion INTEGER (1),
trustLevel INTEGER (0..4),
capabilities SEQUENCE OF UTF8String,
ownerOrganization UTF8String,
platformIdentifier UTF8String,
maxDelegationDepth INTEGER (0..255) OPTIONAL,
killSwitchURI IA5String OPTIONAL,
agentClass INTEGER (0..65535) OPTIONAL,
signingKeyHash OCTET STRING (SIZE(32)) OPTIONAL
}
4.3. Field Definitions
4.3.1. agentVersion
An integer indicating the version of the AgentIdentity extension
structure. This document defines version 1. Implementations
MUST reject certificates with an agentVersion they do not
understand.
Future versions of this specification may add fields to the
SEQUENCE. Implementations SHOULD ignore unknown trailing fields
if the agentVersion is one they support, following the
extensibility model of [RFC5280].
4.3.2. trustLevel
An integer in the range 0 through 4 indicating the graduated
trust level assigned to the agent at the time of certificate
issuance.
The semantics of each trust level are defined in Section 6.
The trust level in the certificate represents the MAXIMUM trust
level the agent is authorized to operate at. A platform MAY
enforce a lower effective trust level at runtime based on
policy, but MUST NOT permit an agent to operate above the
trust level encoded in its certificate.
A certificate with trustLevel 0 indicates an agent with no
verified trust. The CA has verified the certificate request
but makes no assertion about the agent's authorization to
perform any specific action.
4.3.3. capabilities
A SEQUENCE OF UTF8String, where each string names a specific
capability the agent is authorized to exercise. Capability
names are case-insensitive and SHOULD follow the naming
convention defined below.
Capability names MUST consist of lowercase ASCII letters, digits,
and underscores. They MUST be between 1 and 64 characters long.
Examples:
read_data
query_model
send_message
pay
deploy
approve_po
control_device
navigate
An empty capabilities sequence indicates an unrestricted agent
whose permitted actions are governed solely by its trust level.
This is NOT RECOMMENDED for production deployments.
When validating an agent action, the relying party MUST verify
that the requested action is covered by at least one declared
capability, AND that the agent's trust level meets or exceeds
the minimum trust level required for that action category.
4.3.4. ownerOrganization
A UTF8String identifying the organization that owns and is
accountable for the agent's actions. This field enables
attribution of agent behavior to a responsible legal entity.
The ownerOrganization SHOULD match or be a subordinate of
the Organization (O) field in the certificate Subject.
4.3.5. platformIdentifier
A UTF8String identifying the platform that manages the agent's
lifecycle. This field enables relying parties to determine
which platform provisioned the agent and may be used to look
up platform-specific verification endpoints.
Example values:
AgentPass v1.0
Samsung SDS Agent Platform
Kakao Kanana Agent Framework
4.3.6. maxDelegationDepth
An OPTIONAL integer in the range 0 through 255 specifying the
maximum number of delegation hops permitted from this agent.
A value of 0 means this agent MUST NOT delegate to child agents.
A value of 1 means this agent may create child agents, but those
children MUST NOT further delegate. If absent, the platform's
default delegation policy applies.
When a parent agent delegates to a child, the child's
maxDelegationDepth MUST be strictly less than the parent's.
This ensures delegation chains terminate.
4.3.7. killSwitchURI
An OPTIONAL IA5String containing a URI that, when invoked with
an HTTP POST request, triggers immediate cessation of the agent's
operations.
The kill switch endpoint MUST be authenticated. The kill switch
request MUST include the agent's certificate serial number and
MUST be signed by the invoking principal.
The kill switch is a complement to OCSP-based revocation, not a
replacement. OCSP revocation updates the CA's revocation status.
The kill switch directly instructs the platform to halt the agent.
The kill switch MUST be fail-safe: if the endpoint is unreachable,
the platform MUST treat the agent as revoked (fail-closed) rather
than allowing continued operation (fail-open).
4.3.8. agentClass
An OPTIONAL integer in the range 0 through 65535 indicating
the class of the agent. Agent classes categorize agents by
their operational domain. The initial registry of agent
classes is defined in Section 7.
4.3.9. signingKeyHash
An OPTIONAL 32-byte OCTET STRING containing the SHA-256 hash
of the agent's MCPS signing public key, if the agent uses a
separate key for per-message signing via the MCPS protocol
[draft-sharif-mcps-secure-mcp].
This field binds the agent's identity certificate to its MCPS
signing key, enabling relying parties to verify that a signed
message was produced by the agent identified in the certificate.
If the agent uses its certificate key pair for MCPS signing,
this field SHOULD be omitted (the binding is implicit).
5. Certificate Profile
An agent identity certificate conforms to the X.509v3 Internet
certificate profile defined in [RFC5280] with the following
additional constraints.
5.1. Subject Field
The Subject field MUST contain at minimum:
CN (Common Name): The agent's human-readable name.
Example: procurement-bot
O (Organization): The organization that owns the agent.
Example: Samsung Electronics
Additional subject fields (OU, L, ST, C) are OPTIONAL and
follow standard [RFC5280] semantics.
5.2. Subject Alternative Name
The SubjectAlternativeName extension MUST be present and MUST
contain a uniformResourceIdentifier of type URI encoding a
SPIFFE ID [SPIFFE] for the agent:
spiffe://trust-domain/agent/agent-name
Examples:
spiffe://samsung.com/agent/procurement-bot
spiffe://kakao.com/agent/kanana-gift-agent
spiffe://cybersecai.co.uk/agent/data-processor
The SPIFFE trust domain MUST match the domain under which the
owning organization operates. The path component MUST begin
with "/agent/".
Additional SAN entries (DNS names, IP addresses) are permitted
for agents that also serve as network endpoints.
5.3. Key Usage
The Key Usage extension MUST be present and marked critical.
The following bits MUST be set:
digitalSignature
The following bits MUST NOT be set:
keyCertSign
cRLSign
This ensures agent certificates cannot be used to issue
additional certificates or sign CRLs.
5.4. Extended Key Usage
The Extended Key Usage extension SHOULD be present. It SHOULD
contain the following key purpose:
id-kp-agentIdentity OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
private(4) enterprise(1) cybersecai(66339) 2 }
This key purpose identifies the certificate as an agent identity
certificate and prevents its use as a TLS server certificate,
TLS client certificate, or code signing certificate unless
those purposes are also explicitly listed.
5.5. Basic Constraints
The Basic Constraints extension MUST be present and MUST
indicate cA=FALSE. Agent identity certificates are end-entity
certificates.
5.6. Certificate Lifetime
Agent identity certificates SHOULD have a validity period
appropriate to the agent's operational lifetime:
Short-lived agents (task-specific): 1 to 24 hours
Medium-lived agents (session-based): 7 to 30 days
Long-lived agents (persistent): 90 to 365 days
Certificates SHOULD NOT have a validity period exceeding
365 days. Shorter lifetimes reduce the window of exposure
if an agent's private key is compromised.
Platforms SHOULD implement automated certificate renewal
before expiry.
6. Trust Levels
The trust level taxonomy defines five graduated levels of
autonomous authority. Each level subsumes the permissions
of all lower levels.
6.1. Level 0: Unknown
The agent has a certificate but no verified trust relationship.
The agent SHOULD be restricted to read-only, observational
operations with no side effects.
Permitted action categories: read, list, get, monitor,
health, status.
6.2. Level 1: Registered
The agent has been registered with a platform and its identity
has been verified. The agent MAY perform informational
operations that do not modify state.
Permitted action categories: All L0 actions, plus query,
search, classify, summarize, notify, alert.
6.3. Level 2: Verified
The agent has passed additional verification, which MAY include
sanctions screening, owner validation, or organizational policy
checks. The agent MAY perform operations that modify state
within its declared capabilities.
Permitted action categories: All L1 actions, plus call_api,
send_message, create, update, execute, process, transform.
6.4. Level 3: Trusted
The agent is authorized for financial operations and other
high-value actions within its declared capabilities. The
agent's owner organization has explicitly authorized these
operations.
Permitted action categories: All L2 actions, plus pay,
transfer, invoice, purchase, approve_po, financial.
Financial operations at L3 SHOULD include counterparty
sanctions screening before execution.
6.5. Level 4: Critical
The agent is authorized for irreversible or high-impact
operations that require human-in-the-loop approval before
execution.
Permitted action categories: All L3 actions, plus deploy,
delete, destroy, drop, purge, production, large_payment.
L4 operations MUST NOT execute without explicit human
approval. The approval mechanism MAY be:
(a) A software-based approval workflow with authenticated
human confirmation.
(b) A hardware-based approval device (e.g., a physical key
or token) that produces a cryptographically signed
approval receipt.
The approval receipt MUST be recorded in the audit ledger
alongside the action.
7. Agent Classes
Agent classes provide a coarse categorization of agents by
operational domain. The following initial values are defined:
0 Unclassified
1 Data Processing Agent
2 Financial Agent
3 Communication Agent
4 DevOps / Deployment Agent
5 Security / Monitoring Agent
6 Physical / Robotics Agent
7 IoT / Device Control Agent
8 Search / Discovery Agent
9 Procurement / Supply Chain Agent
10 Legal / Compliance Agent
11 Creative / Content Agent
12 Orchestration Agent
Values 13 through 999 are reserved for future standardization.
Values 1000 through 65535 are available for private use.
IANA is requested to maintain a registry of agent class values
as specified in Section 16.2.
8. Delegation Model
8.1. Scope Attenuation
When a parent agent delegates authority to a child agent by
requesting a child agent identity certificate, the following
constraints MUST hold:
(a) The child's trustLevel MUST be less than or equal to the
parent's trustLevel.
(b) The child's capabilities MUST be a subset of the parent's
capabilities. A child MUST NOT possess capabilities not
held by its parent.
(c) The child's maxDelegationDepth MUST be strictly less than
the parent's maxDelegationDepth.
These constraints ensure that delegation can only narrow
authority, never broaden it.
8.2. Delegation Chain Validation
A relying party validating a delegated agent's certificate
SHOULD verify the delegation chain by:
(a) Validating the child's certificate chain to a trusted root.
(b) Verifying that each hop in the delegation chain satisfies
the scope attenuation rules in Section 8.1.
(c) Verifying that no certificate in the chain has been revoked.
The delegation chain is established through the certificate
Subject and Issuer fields, combined with a delegation reference
in the child's AgentIdentity extension or through an out-of-band
ledger maintained by the platform.
9. Revocation and Kill Switch
9.1. OCSP Integration
Agent identity certificates SHOULD include an Authority
Information Access (AIA) extension pointing to an OCSP
responder, per [RFC6960].
Relying parties SHOULD perform OCSP checking on every agent
interaction, not only at session establishment. Agent
operations occur at machine speed; a revoked agent can cause
significant damage in the interval between OCSP checks.
CAs issuing agent identity certificates SHOULD support OCSP
stapling and SHOULD update OCSP responses within 60 seconds
of a revocation event.
9.2. Kill Switch Semantics
The kill switch provides a direct, out-of-band revocation
mechanism that operates independently of the CA's OCSP
infrastructure.
When the kill switch URI is invoked:
(a) The platform MUST immediately halt all operations of
the identified agent.
(b) The platform MUST update its local revocation status
for the agent.
(c) The platform SHOULD notify the issuing CA to update
the certificate's OCSP status.
(d) The platform MUST record the kill switch invocation
in its audit ledger, including the invoking principal,
timestamp, and reason.
Kill switch invocations are irrevocable within the lifetime
of the certificate. A killed agent MUST NOT be reactivated.
A new certificate MUST be issued to resume operations.
9.3. Hardware Kill Switch
For L4 agents, the kill switch MAY be implemented through a
hardware device that requires physical human interaction to
approve critical operations and that can halt agent operations
through a physical control.
The hardware device SHOULD produce a cryptographically signed
approval or denial receipt using a device-resident key that
cannot be extracted. The receipt SHOULD be recorded in the
audit ledger.
10. Relationship to SPIFFE
This profile uses SPIFFE Verifiable Identity Documents (SVIDs)
[SPIFFE] as the foundation for agent identity within the
SubjectAlternativeName extension.
The SPIFFE ID provides workload identity: it identifies the
agent within a trust domain. The AgentIdentity extension
provides agent-specific metadata: trust level, capabilities,
delegation constraints, and revocation control.
Together, the SPIFFE ID and AgentIdentity extension provide
a complete agent identity that is both interoperable with
existing SPIFFE infrastructure and enriched with the metadata
necessary for agent-specific authorization decisions.
Platforms that already use SPIFFE for workload identity can
adopt this profile by adding the AgentIdentity extension to
their existing SVID issuance pipeline.
11. Relationship to MCPS
MCPS (MCP Secure) [draft-sharif-mcps-secure-mcp] defines a
cryptographic signing layer for AI agent communications. MCPS
provides per-message signing, replay protection, and tool
integrity verification.
This certificate profile complements MCPS by providing the
identity foundation that MCPS signing operations reference.
Specifically:
(a) The agent's MCPS signing key MAY be the same key pair
used in the agent identity certificate, or a separate
key pair.
(b) If a separate MCPS signing key is used, the
signingKeyHash field in the AgentIdentity extension
binds the certificate to the MCPS key.
(c) MCPS message signatures reference the agent's SPIFFE ID
from the certificate SAN, enabling relying parties to
look up the certificate and validate the trust level.
(d) The trust level in the certificate provides the upper
bound for MCPS trust negotiation.
12. CA Issuance Procedures
Certificate authorities issuing agent identity certificates
MUST perform the following validation steps.
12.1. Agent Identity Validation
The CA MUST verify that the certificate request was generated
by an authorized platform operating on behalf of the claimed
owner organization.
The CA MUST verify that the SPIFFE trust domain in the
requested SAN corresponds to a domain controlled by the
requesting organization.
The CA SHOULD verify the identity of the requesting
organization through existing OV (Organization Validation)
or EV (Extended Validation) procedures.
12.2. Capability Attestation
The CA is NOT required to validate the semantic correctness
of the requested capabilities. Capability validation is the
responsibility of the platform and the relying party.
The CA MUST ensure that the capabilities are syntactically
valid per Section 4.3.3.
12.3. Certificate Transparency
CAs SHOULD submit agent identity certificates to Certificate
Transparency (CT) logs per [RFC9162]. This enables public
auditability of agent identity certificate issuance.
CAs SHOULD include Signed Certificate Timestamps (SCTs)
in issued certificates.
13. Relying Party Verification
A relying party receiving an agent identity certificate
MUST perform the following verification steps:
(a) Validate the certificate chain to a trusted root per
[RFC5280].
(b) Verify the certificate has not expired.
(c) Check revocation status via OCSP [RFC6960] or CRL.
(d) Parse the AgentIdentity extension and verify the
agentVersion is supported.
(e) Verify the agent's trustLevel meets or exceeds the
minimum required for the requested action.
(f) Verify the requested action is covered by the agent's
declared capabilities.
(g) If a delegation chain is present, verify scope
attenuation per Section 8.
If any verification step fails, the relying party MUST
reject the agent's request and SHOULD log the failure.
14. Security Considerations
14.1. Trust Level Escalation
An attacker who compromises a platform could issue certificates
with elevated trust levels. CAs SHOULD implement rate limiting
and anomaly detection on certificate requests. A sudden
increase in L3 or L4 certificate requests from a single
platform SHOULD trigger an alert.
14.2. Capability Inflation
An agent could request a certificate with more capabilities
than it needs. Platforms SHOULD enforce the principle of
least privilege by requesting only the capabilities required
for the agent's intended function.
14.3. Kill Switch Availability
The kill switch endpoint is a critical safety mechanism. If
the endpoint is unavailable, the platform MUST default to
treating the agent as revoked (fail-closed). Kill switch
endpoints SHOULD be deployed with high availability and
SHOULD NOT be hosted on the same infrastructure as the agent.
14.4. Delegation Depth Exhaustion
An agent with a high maxDelegationDepth could create deep
delegation chains that are difficult to audit. Platforms
SHOULD set a low default maxDelegationDepth (2 or 3) and
require explicit authorization for higher values.
14.5. Agent Impersonation
An attacker who obtains an agent's private key can
impersonate the agent. Agent private keys MUST be stored
securely, preferably in hardware security modules (HSMs),
trusted platform modules (TPMs), or secure enclaves.
Platforms SHOULD implement key rotation policies and SHOULD
use short-lived certificates to limit the window of exposure.
14.6. Compromised Platform Keys
If a platform's CSR signing key is compromised, an attacker
could request certificates for rogue agents. CAs SHOULD
implement mutual TLS or other strong authentication for
platform-to-CA communication.
14.7. Clock Skew and Certificate Lifetime
Short-lived certificates are more resilient to key compromise
but are sensitive to clock skew between the platform, CA, and
relying parties. Implementations SHOULD allow a clock skew
tolerance of no more than 5 minutes.
14.8. Cross-Domain Trust
When agents from different trust domains interact, each
relying party MUST independently validate the other agent's
certificate chain and MUST NOT trust a foreign trust domain's
assertions about trust level or capabilities without explicit
cross-domain trust configuration.
15. Jurisdictional Binding
Jurisdictional binding provides cryptographic enforcement of
geographic and regulatory restrictions on agent operations.
Because the jurisdiction is embedded in the X.509 certificate
signed by the issuing CA, it cannot be modified by the agent
or any intermediary without invalidating the certificate
signature.
15.1. Jurisdiction OID Arc
Jurisdictional bindings are expressed using the OID arc
id-cybersecai 6, with the following defined values:
id-jur-eu ::= { id-cybersecai 6 1 } -- European Union
id-jur-uk ::= { id-cybersecai 6 2 } -- United Kingdom
id-jur-latam ::= { id-cybersecai 6 3 } -- Latin America
id-jur-apac ::= { id-cybersecai 6 4 } -- Asia-Pacific
id-jur-us ::= { id-cybersecai 6 5 } -- United States
id-jur-mea ::= { id-cybersecai 6 6 } -- Middle East & Africa
Additional jurisdiction values MAY be registered via the
AIC Jurisdiction Registry (Section 17.6).
15.2. Certificate Extension Format
When jurisdictional binding is used, the issuing Certificate
Authority MUST include a non-critical X.509v3 extension with
OID from the id-cybersecai 6 arc. The extension value is an
ASN.1 UTF8String containing the jurisdiction code.
Multiple jurisdiction OIDs MAY be included in a single
certificate to permit operations across multiple regions.
AgentJurisdiction ::= SEQUENCE {
jurisdictions SEQUENCE OF UTF8String
}
15.3. Enforcement
Implementations that process AIC certificates containing
jurisdictional binding extensions MUST verify that the target
resource or operation falls within the agent's permitted
jurisdiction before executing the action.
The mechanism for determining the jurisdiction of a target
resource is deployment-specific. Common approaches include:
1. Cloud region identifiers (e.g., "eu-west-1",
"ap-northeast-2") embedded in action parameters.
2. DNS-based geolocation of the target endpoint.
3. Operator-configured jurisdiction mappings for internal
services.
If the target jurisdiction does not match any of the agent's
permitted jurisdictions, the implementation MUST reject the
request and MUST NOT forward, execute, or relay the message.
The rejection MUST be logged in the audit trail with the
agent identifier, jurisdiction OID(s), target jurisdiction,
action requested, timestamp, and rejection reason.
15.4. Interaction with Trust Levels
Jurisdictional binding operates independently of trust levels.
An agent MAY hold trust level L4 (Critical) but still be
restricted to a single jurisdiction.
The jurisdiction check MUST be applied BEFORE the trust level
check. An agent that fails the jurisdiction check MUST NOT
proceed to trust level evaluation.
15.5. Fail-Closed Requirement
If the jurisdiction of a target resource cannot be determined,
implementations MUST reject the request rather than permit it.
15.6. Regulatory Alignment
The jurisdictional binding mechanism is designed to support
compliance with data sovereignty requirements including but
not limited to:
o EU AI Act (Regulation 2024/1689)
o UK Data Protection Act 2018
o Brazil LGPD (Lei Geral de Protecao de Dados)
o Saudi Arabia PDPL (Personal Data Protection Law)
o UAE Federal Decree-Law No. 45/2021
The binding is enforcement-ready: the jurisdiction is
cryptographically bound to the agent's identity certificate
and verified at runtime before any action executes.
16. Privacy Considerations
Agent identity certificates may reveal information about an
organization's agent deployment, including the number of
agents, their capabilities, and their trust levels.
Organizations that consider their agent deployment
architecture to be confidential SHOULD:
(a) Use short-lived certificates to limit the window during
which certificate metadata is valid.
(b) Use generic capability names that do not reveal
business-specific operations.
(c) Consider using CT log redaction mechanisms if available.
The ownerOrganization field reveals the deploying entity.
This is intentional for accountability but may be undesirable
in some contexts. Organizations MAY use a subsidiary or
operating entity name rather than the parent organization.
16. IANA Considerations
16.1. CyberSecAI OID Arc
All OIDs defined in this document are allocated under the
CyberSecAI Private Enterprise Number arc:
id-cybersecai OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
private(4) enterprise(1) 66339 }
IANA PEN 66339 was assigned to CyberSecAI Ltd on
22 July 2026.
16.2. OID Arc Structure
The following sub-arcs are defined under id-cybersecai:
Certificate Policies (id-cybersecai 1):
id-acp-agentValidated ::= { id-cybersecai 1 1 }
id-acp-orgAgentValidated ::= { id-cybersecai 1 2 }
id-acp-extAgentValidated ::= { id-cybersecai 1 3 }
id-acp-autonomousAgent ::= { id-cybersecai 1 4 }
These policy OIDs indicate the level of validation
performed before issuing an Agent Identity Certificate:
Agent-Validated (AV): The CA verified the agent name
and its binding to a cryptographic key pair.
Organization-Agent-Validated (OAV): The CA verified
the agent and the identity of the operating
organization.
Extended-Agent-Validated (EAV): The CA performed
extended due diligence on the agent, operator,
organization, and operational context.
Autonomous-Agent (AA): The agent operates without a
human operator. The CA verified the deploying
organization and the autonomous operational parameters.
Certificate Extensions (id-cybersecai 2):
id-pe-agentIdentity ::= { id-cybersecai 2 1 }
id-pe-agentTrustLevel ::= { id-cybersecai 2 2 }
id-pe-agentCapabilityManifest ::= { id-cybersecai 2 3 }
id-pe-agentDelegationChain ::= { id-cybersecai 2 4 }
id-pe-mcpsSigningPolicy ::= { id-cybersecai 2 5 }
The AgentIdentity extension (id-pe-agentIdentity) is
defined in Section 4.1 of this document.
The AgentTrustLevel extension encodes the agent's
graduated trust level (L0 through L4) as defined in
the trust gating model.
The AgentCapabilityManifest extension lists the
permitted actions for the agent.
The AgentDelegationChain extension records the chain
of delegation from the original authorizing entity
to the current agent.
The MCPSSigningPolicy extension specifies the signing
requirements for messages sent by the agent under
the MCPS protocol.
Extended Key Usage (id-cybersecai 3):
id-kp-agentAuth ::= { id-cybersecai 3 1 }
id-kp-agentSigning ::= { id-cybersecai 3 2 }
id-kp-agentPayment ::= { id-cybersecai 3 3 }
id-kp-agentDelegation ::= { id-cybersecai 3 4 }
agentAuth: The certificate may be used for
agent-to-agent or agent-to-service authentication.
agentSigning: The certificate may be used for
MCPS per-message cryptographic signing.
agentPayment: The certificate may be used for
agent-initiated payment authorization.
agentDelegation: The certificate may be used for
delegating authority to subordinate agents.
Attribute Types (id-cybersecai 4):
id-at-agentOperator ::= { id-cybersecai 4 1 }
id-at-agentModel ::= { id-cybersecai 4 2 }
id-at-agentVersion ::= { id-cybersecai 4 3 }
Protocol Identifiers (id-cybersecai 5):
id-proto-mcps ::= { id-cybersecai 5 1 }
id-proto-lattp ::= { id-cybersecai 5 2 }
id-proto-attp ::= { id-cybersecai 5 3 }
Jurisdictional Binding (id-cybersecai 6):
id-jur-eu ::= { id-cybersecai 6 1 }
id-jur-uk ::= { id-cybersecai 6 2 }
id-jur-latam ::= { id-cybersecai 6 3 }
id-jur-apac ::= { id-cybersecai 6 4 }
id-jur-us ::= { id-cybersecai 6 5 }
id-jur-mea ::= { id-cybersecai 6 6 }
These OIDs restrict the agent to operating within the
specified geographic or regulatory jurisdiction. See
Section 15 for enforcement requirements.
16.3. Certificate Policy Requirements
A CA issuing Agent Identity Certificates MUST include at
least one of the certificate policy OIDs defined in
Section 16.2 in the certificatePolicies extension of each
issued AIC. The policy OID indicates the validation level
the CA performed and the associated CP/CPS requirements.
CAs MUST NOT assert a policy OID unless their certificate
practice statement meets the corresponding validation
requirements.
16.4. Agent Class Registry
IANA is requested to create a new registry titled "X.509
Agent Identity Certificate Agent Classes" with the following
registration policy:
Values 0-12: Defined in this document (Section 7).
Values 13-999: Standards Action required.
Values 1000-65535: First Come First Served.
16.5. Extended Key Usage Registration
IANA is requested to register the following Extended Key
Usage OIDs in the "SMI Security for PKIX Extended Key
Purpose" registry:
id-kp-agentAuth { id-cybersecai 3 1 }
id-kp-agentSigning { id-cybersecai 3 2 }
id-kp-agentPayment { id-cybersecai 3 3 }
id-kp-agentDelegation { id-cybersecai 3 4 }
17. References
17.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.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280,
DOI 10.17487/RFC5280, May 2008.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public
Key Infrastructure Online Certificate Status Protocol
- OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling,
"Certificate Transparency Version 2.0", RFC 9162,
DOI 10.17487/RFC9162, December 2021.
17.2. Informative References
[SPIFFE] Feldman, E., et al., "Secure Production Identity
Framework for Everyone (SPIFFE)", available at
https://spiffe.io/docs/latest/spiffe-about/overview/
[draft-sharif-mcps-secure-mcp]
Sharif, R., "MCPS: Cryptographic Security Layer for
the Model Context Protocol",
draft-sharif-mcps-secure-mcp-02, March 2026.
[draft-sharif-agent-payment-trust]
Sharif, R., "Agent Payment Trust: Cryptographic
Authorization for Autonomous Agent Financial
Operations", draft-sharif-agent-payment-trust,
March 2026.
[draft-sharif-openid-agent-identity]
Sharif, R., "OpenID Agent Identity: Verifiable
Identity for Autonomous AI Agents",
draft-sharif-openid-agent-identity, March 2026.
Appendix A. Example Agent Certificate
The following shows an example agent identity certificate
with the AgentIdentity extension:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
58:31:4c:ee:1d:a9:95:79:52:f2:16:14:86:92:c3:ff
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=CrossCert Agent Identity CA,
O=Korea Electronic Certification Authority,
C=KR
Validity:
Not Before: Jul 20 00:00:00 2026 GMT
Not After: Jul 20 00:00:00 2027 GMT
Subject: CN=procurement-bot,
O=Samsung Electronics,
C=KR
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage:
id-kp-agentIdentity
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Alternative Name:
URI:spiffe://samsung.com/agent/procurement-bot
X509v3 Authority Information Access:
OCSP - URI:http://ocsp.crosscert.com
AgentIdentity:
agentVersion: 1
trustLevel: 2
capabilities: search_suppliers,
negotiate,
purchase,
approve_po
ownerOrganization: Samsung Electronics -
Semiconductor Division
platformIdentifier: AgentPass v1.0
maxDelegationDepth: 2
killSwitchURI: https://agentpass.samsung
.com/api/agents/kill
agentClass: 9
signingKeyHash: a4f8c2e1... (32 bytes)
The example shows a procurement agent operated by Samsung
Electronics, issued by CrossCert (Korea's CA), with L2 trust,
four declared capabilities, and a maximum delegation depth of 2.
Appendix B. ASN.1 Module
AgentIdentityCertificateProfile-2026
{ iso(1) identified-organization(3) dod(6) internet(1)
private(4) enterprise(1) cybersecai(66339) 0 1 }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS
-- nothing imported; self-contained module
;
-- Agent Identity Extension
id-pe-agentIdentity OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
private(4) enterprise(1) cybersecai(66339) 1 }
AgentIdentity ::= SEQUENCE {
agentVersion INTEGER (1),
trustLevel TrustLevel,
capabilities Capabilities,
ownerOrganization UTF8String (SIZE(1..256)),
platformIdentifier UTF8String (SIZE(1..256)),
maxDelegationDepth INTEGER (0..255) OPTIONAL,
killSwitchURI IA5String (SIZE(1..2048)) OPTIONAL,
agentClass AgentClass OPTIONAL,
signingKeyHash OCTET STRING (SIZE(32)) OPTIONAL
}
TrustLevel ::= INTEGER {
unknown (0),
registered (1),
verified (2),
trusted (3),
critical (4)
} (0..4)
Capabilities ::= SEQUENCE OF Capability
Capability ::= UTF8String (SIZE(1..64))
AgentClass ::= INTEGER {
unclassified (0),
dataProcessing (1),
financial (2),
communication (3),
devops (4),
security (5),
robotics (6),
iot (7),
search (8),
procurement (9),
legal (10),
creative (11),
orchestration (12)
} (0..65535)
-- Agent Identity Extended Key Usage
id-kp-agentIdentity OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
private(4) enterprise(1) cybersecai(66339) 2 }
END
Author's Address
Raza Sharif
CyberSecAI Ltd
London, United Kingdom
Email: raza@cybersecai.co.uk
URI: https://agentpass.co.uk