Internet Engineering Task Force R. Sharif Internet-Draft CyberSecAI Ltd Intended status: Standards Track July 22, 2026 Expires: January 22, 2027 X.509 Certificate Profile for Autonomous AI Agent Identity draft-sharif-x509-agent-identity-profile-01 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 22, 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. 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. OID Registration IANA is requested to register the following OIDs under the CyberSecAI Private Enterprise Number arc: id-pe-agentIdentity: For the AgentIdentity X.509v3 extension (Section 4.1). id-kp-agentIdentity: For the agent identity Extended Key Usage purpose (Section 5.4). The specific OID values will be assigned upon allocation of the CyberSecAI Private Enterprise Number (IANA PEN 66339 (assigned 22 July 2026)). 16.2. 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.3. Extended Key Usage Registration IANA is requested to register the id-kp-agentIdentity Extended Key Usage OID in the "SMI Security for PKIX Extended Key Purpose" registry. 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