]> Security Requirements for AI Agents Huawei
niyuan1@huawei.com
Huawei
liuchunchi@huawei.com
Huawei
gaoqiangzhou@huawei.com
robinli314@163.com
CESI
xuyuna@cesi.cn
AI Agent Provisioning Authentication Authorization This document discusses security requirements for AI agents, covering different stages of security interactions. These include provisioning, registration, discovery, cross-domain interconnection, and access control. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the WG Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .
Introduction With the widespread application of agentic AI technology across various business scenarios, its security issues have become increasingly prominent. This document aims to provide an architecture addressing security requirements across different stages of interactions in agentic AI use cases. These include provisioning, registration, discovery, cross-domain interconnection, and access control. This document establishes a starting point to guide discussions on agentic AI security design, development, and implementation. The target audience of this document is IETF security experts who wish to understand AI agents' behavioral patterns and evaluate whether the proposed security requirements are worthy of further security designs.
Architecture 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. Agent +----> Agent | | | +----+-----+ +----------+ +----+-----+ | | | | | | +--v---------+ +---------v---+ | | | DB | | API | | | +------------+ +-------------+ | +----------------------------------------------------+ ]]> Figure 1. Architecture of Agent Security Control and Management The architecture of agent security control and management is illustrated in Figure 1. There are three types of security interactions, in sequential order:
  1. Provisioning, Registration, and Discovery: Creating agent identities, establishing initial trust, provisioning agent secrets and credentials, and onboarding agents to enable discovery.
  2. Cross-Domain Interconnection: Enabling secure, authenticated communication between agents across different trust domains.
  3. Access Control: The Master Agent validates both intra-domain and inter-domain access tokens, creates internal workflows, and manages different credentials for heterogeneous systems.
Therefore, the architecture includes four components:
  1. Firewall: A network security device designed to monitor, filter, and control incoming and outgoing network traffic based on predetermined security rules.
  2. Master Agent: The central orchestrating entity that manages multi-agent operations, including cross-domain communication, workflow coordination, credential management, and security policy management.
  3. Agents: Autonomous software entities deployed in various domains to perform specific tasks.
  4. Heterogeneous Systems: API endpoints, microservices, tools, and databases.
The above architecture is presented from the perspective of a service flow. From the identity management perspective, we recommend reusing existing IETF work such as WIMSE. The draft discusses the applicability of WIMSE to agentic AI.
Provisioning, Registration, and Discovery Figure 2 shows the diagram of provisioning and registration, which includes Agent Credential Authority (ACA) and Agent Registry Service (ARS):
  1. ACA (Agent Credential Authority): A trusted third party that issues and manages credentials for agents. Credential formats include, but are not limited to, X.509 certificates and identity tokens.
  2. ARS (Agent Registry Service): A system responsible for agent identity registration and discovery.
Agent +----+| | | | +----------+ | | | | | | | | device/container | | | +-----------------------+ | | | +-------------------------------------------+ ]]> Figure 2. Diagram for Provisioning and Registration
Identity Provisioning and Management Identity provisioning and management involve creating and assigning a verifiable digital identity to an agent.
  • Initial Trust Establishment: Initial trust can be established through one or more of the following trust anchors, including, but not limited to: a manufacturer-embedded immutable credential like an IDevID certificate; a hardware root of trust like a Trusted Platform Module (TPM) or Hardware Security Module (HSM); identity documents like an AWS Instance Identity Document or an Azure Managed Service Identity token. This step verifies the agent's execution environment (device, container, etc.) as trustworthy, allows the device or container to join the network, thereby enabling secure operations for all subsequent steps.
  • Credential Request: During a credential request, the agent must provide multiple proofs of its legitimacy, could include, for example, but not limited to:
    • Proof of Possession (PoP): A Certificate Signing Request (CSR) or other PoP forms signed with the agent's private key, demonstrating that the agent holds the private key corresponding to the requested identity.
    • Remote Attestation Evidence or Result: A set of security-relevant claims about the Target Environment submitted to a RATS Verifier (which could be the ACA), providing information about operational status, health, configuration, or construction.
    • AI Bill of Materials (AIBOM): A comprehensive inventory that details the agent's supply chain, including models, datasets, configurations, dependencies, and related infrastructure. This prevents the use of vulnerable AI components.
    • Provider Endorsement: A digital signature or credential from the Agent Provider, ensuring the agent originated from a trusted source.
    • Identity Binding: A cryptographic binding to a specific human user or an organizational role to specify on whose behalf the agent operates and its authorized scope.
  • Credential Issuance: The ACA validates proofs and requests from the above two steps, if passed, it issues an agent-specific credential that may include its owner or requester identity, capabilities, locator, acceptable validation methods for the ARS.
  • Credential Lifecycle Management: The ACA not only issues credentials but also defines and enforces revocation policies. These policies are triggered by specific events, such as a detected security compromise, the agent's scheduled decommissioning, or key rotation.
Secret Management AI agents SHOULD NOT have direct access to secrets due to new threats like Prompt Injection. AI Agents SHOULD reuse secret management modules on the platform it operates on, for example, cloud secret managers or TEE/keystore/keychains on smart devices. Best practices like secret/credential generation, rotation and revocation apply. Agents SHOULD only obtain temporary access tokens or signed messages via a secure API or other kind of trusted intermediary. Guardrails also apply for general secret information exfiltration prevention.
Agent Registration After receiving a credential from the ACA, the agent then sends it to the ARS to authenticate itself and start the registration process.
  • Authentication: The ARS must verify the legitimacy of the credential submitted by the agent. It must be signed or otherwise endorsed by the ACA.
  • Registration: The ARS then checks if the information signed by the ACA, such as the agent's capabilities, exactly matches the registration request sent by the agent. Upon successful validation, the ARS assigns the agent a unique identifier and establishes an agent record that links the identifier to its attributes.
  • Record Management: The ARS removes expired credentials and synchronizes with the ACA to ensure timely revocation of credentials, preventing the use of invalid or compromised credentials.
Agent Onboarding Agent onboarding differs between campus and cloud environments. On campus, agents use protocols like EAP-TLS for network access. In the cloud, the process involves injected sidecars, which register agents to the central service mesh registry automatically to enable communication and management.
Agent Discovery After agent onboarding, the discovery process enables entities (e.g., a human user, an agent, etc.) to find and connect with registered agents.
  • Authentication: The ARS must authenticate the entity initiating the discovery request. The requester is required to present a valid identity credential.
  • Capability Filtering and Matching: The ARS performs dynamic filtering based on the requester’s identity and query and returns only agent records relevant to the query, enforcing the principle of least privilege at the discovery layer.
  • Cross-Domain Agent Discovery: The ARS should support the discovery of trust bundles for verifying agent identities across administrative domains. proposes a DNS-like discovery architecture in which Agent Registries manage domain-level trust bundles, enabling agent identities registered in one administrative domain to be verified across domains.
Cross-Domain Interconnection
Cross-Domain Identifier Interoperability Different domains may use distinct identifier schemas. Possible methods include:
  • Pre-configured schema translation
  • Cross-domain identifier synchronization
  • A universal parsing framework or system
Secure Cross-Domain Transmission A mutual TLS (mTLS) connection is established between the external requesting agent and the master agent. The master agent terminates the mTLS connection and parses application-layer requests. In this case, the master agent functions as an OAuth resource server and manages internal task orchestration.
Authenticating External Calls The master agent then verifies the identity of the requesting agent, and whether or not it has permission to the requested service or agent. Different authentication methods might be possible:
  • API keys
  • Username-password
  • Pre-shared secrets
  • Assertions (for example, JWT Authorization Grants as discussed in )
These methods may also be combined using AND/OR logic. During this process, the master agent might be able to identify the caller endpoint type:
  • Human user via browser or app
  • Human user via API
  • AI agents
  • Hardware or equipment via an IoT API
IAM Integration Since the agent may inherit its access rights from its owner or user, when authenticating requests, the validation might require integration of IAM systems for redirected verification.
Access Control
Authorization Handling The master agent acts as the OAuth 2.1 resource server and a Policy Enforcement Point (PEP). Its responsibilities are as follows:
  • Token Validation: The master agent must validate access tokens as described in OAuth 2.1 Section 5.2. If validation fails, it must respond according to OAuth 2.1 Section 5.3 error handling requirements.
  • Fine-Grained Policy Enforcement: The master agent serves as a PEP that queries a PDP (Policy Decision Point), such as Open Policy Agent (OPA), to evaluate the requester’s access request. The PDP functions by taking the master agent's query, pre-configured policies (supporting RBAC, ABAC, ReBAC models, etc.), and data as inputs to decide whether the requester is authorized for its intended action. The PDP then returns the final decision to the master agent for enforcement.
Authorization Models In enterprise environments, Role-based Access Control (RBAC) Attribute-based Access Control (ABAC) or Adaptive Access Control (AdBAC) are different access control models used in practice. Regarding access control models, there are 2 ways forward:
  • whatever the authorization model used in the enterprise itself applies to AI Agents. This leaves 2 cases possible:
    • The agent carries the identity and inherit access rights from its owner (a human or a department). Carrying such human identity will help security control points make decisions with sufficient context, and to the discretion of its internal security policy plus access control model.
    • The agent does not carry the identity from its owner. It carries independent security contexts rich enough for access control.
  • AI Agents require a new authorization model completely.
This section would require more discussion for best current practices.
Authorization Chaining Across Domains In an agentic AI use case, a request may traverse multiple master agents in multiple trust domains before completing. It is common that the requesting agent from domain A needs to access the master agent of domain B. During this process, the following information should be preserved:
  • Original requesting agent identity
  • Authorization context
    • Scope
    • Resource
    • Audience
    • Grant type
    • Assertion
  • Agent-to-Agent Context
The Identity Chaining specification supports the propagation of identity and authorization information across domains. Building on this, the Cross-Domain Transaction Tokens draft explores how workflow context can be securely transferred across domains to support the issuance of Transaction Tokens for downstream workflows.
Converting to Internal Workflow Complex tasks often require multi-agent collaboration. The master agent receives, parses, and extracts the original job request from the external requesting agent, then creates sequential workflows or parallel calls. This requires the master agent to have information about all callable internal API assets, agent capabilities, etc.
  • Batch Authorization Delegation: Parallel execution by multiple downstream agents may require different permissions for each subtask. The Batch Authorization Delegation draft proposes requesting multiple fine-grained permissions in a single authorization request, specifying the designated agent for each permission, and enabling each agent to obtain an appropriately scoped access token through token exchange.
  • Downscoping: If the master agent intends to use a workflow, it extracts the original caller's identity and authorization context, and initiates a new internal workflow. It should follow the principle of least privilege through Transaction Token downscoping, as specified in . The access rights to each downstream workload decrease.
  • Agent-to-Agent Context: The agent-to-agent context and intent of the original requester must be preserved and propagated throughout the workflow to avoid authorization drift and context poisoning.
Interoperability for Heterogeneous Systems Within a domain, there might exist different types of heterogeneous systems or legacy systems that require different authentication methods. They could be API endpoints, microservices, tools or databases. The exact authentication methods are determined by the service itself, for example:
  • Identity tokens
  • API keys
  • Pre-shared secrets
  • Username-password
  • X.509 certificates
As a result, the master agent also works as an intermediary credential manager that converts the formats, scopes, identity of the credential, bridging the gap between heterogeneous systems and platforms. Examples include:
  • Static secrets (API keys) to be exchanged to short-lived, on demand credentials (identity tokens)
Zero Trust Analysis The above information can be used as rich context that allows zero trust access control. There are three additional aspects that can be implemented to enhance the zero trust framework:
  • Remote Attestation Results: For the PEP at the master agent or the internal resource server, Remote attestation results could also be part of the inputs, which could include the following information:
    • Roots of Trust (RoT) and trust anchors
    • Identifiers
    • Affiliations
    • Posture assessment results
    • Capabilities
  • Continuous Observability: The system should utilize OpenTelemetry (OTel) to track each call across agents, sending OTel’s telemetry, which records call frequency, error rates, and behavioral anomalies, etc. to the PDP for real-time assessment.
  • Microsegmentation: Based on the telemetry data, PDP can issue software-defined security policies to PEP at the perimeter of each segment to enforce microsegmentation, in order to prevent lateral movement of security risks. Possible granularity of microsegmentation includes:
    • per IP segment/subnet
    • per workload
    • per tags and attributes (of workload), etc.
IANA Considerations This document has no IANA actions.
References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References OAuth Identity and Authorization Chaining Across Domains Defakto Security Defakto Security MITRE NSA-CCSS Ping Identity Okta This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed. Transaction Tokens CrowdStrike Practical Identity LLC Defakto Security Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the Trust Domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. WIMSE Applicability for AI Agents Huawei Huawei Sandelman Software Works This document discusses WIMSE applicability to Agentic AI, so as to establish independent identities and credential management mechanisms for AI agents. It also discusses mechanisms for cryptographically binding an AI agent identity to an accountable user or organization. DNS-like Agent Discovery Architecture CNNIC Huawei Jinan University China Mobile CNNIC This document defines a DNS-like three-tier agent-discovery architecture for the Internet of Agents (IoA). It introduces three core functional roles: Agent Root, Agent Registry, and Agent Resolver. Cross-domain Transaction Tokens Huawei Huawei This document describes a mechanism for Cross-Domain Transaction Tokens, which enables the safe maintenance and propagation of user identity, workload identities, and authorization context across multiple trust domains. Batch Authorization Delegation Huawei Huawei This document describes a mechanism for Batch Authorization Delegation, which enables a batch of fine-grained, actor-bound permissions in a single request and securely delegates them to multiple collaborating actors.
Revision History
Changes from -00 to -01
  • Expanded the security architecture to include agent discovery.
  • Added requirements for secret management and agent discovery.
  • Refined authorization models, cross-domain authorization, and internal workflow handling.
  • Expanded zero trust considerations, including microsegmentation.
Changes from -01 to -02
  • Add cross-domain agent discovery and trust bundle considerations.
  • Add cross-domain workflow context propagation.
  • Add batch authorization delegation for parallel multi-agent workflows.
  • Update references and fix editorial issues.