



agent2agent                                                        Y. Ni
Internet-Draft                                                 C. P. Liu
Intended status: Informational                                   N. Geng
Expires: 6 May 2026                                               Q. Gao
                                                                Z. R. Li
                                                                  Huawei
                                                         2 November 2025


                  Security Requirements for AI Agents
             draft-ni-a2a-ai-agent-security-requirements-00

Abstract

   This document discusses security requirements for AI agents, covering
   different stages of security interactions.  These include
   provisioning, registration, cross-domain interconnection, and access
   control.

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 6 May 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Ni, et al.                 Expires 6 May 2026                   [Page 1]

Internet-Draft         agent-security-requirements         November 2025


   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.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Provisioning and Registration . . . . . . . . . . . . . . . .   4
     3.1.  Identity Provisioning and Management  . . . . . . . . . .   5
     3.2.  Agent Registration  . . . . . . . . . . . . . . . . . . .   6
     3.3.  Agent Onboarding  . . . . . . . . . . . . . . . . . . . .   6
   4.  Cross-Domain Interconnection  . . . . . . . . . . . . . . . .   6
     4.1.  Cross-Domain Identifier Interoperability  . . . . . . . .   6
     4.2.  Secure Cross-Domain Transmission  . . . . . . . . . . . .   7
     4.3.  Authenticating External Calls . . . . . . . . . . . . . .   7
     4.4.  IAM Integration . . . . . . . . . . . . . . . . . . . . .   7
   5.  Access Control  . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Authorization Handling  . . . . . . . . . . . . . . . . .   8
     5.2.  Authorization Chaining Across Domains . . . . . . . . . .   8
     5.3.  Converting to Internal Workflow . . . . . . . . . . . . .   8
     5.4.  Interoperability for Heterogeneous Systems  . . . . . . .   9
     5.5.  Zero Trust Analysis . . . . . . . . . . . . . . . . . . .   9
     5.6.  Microsegmentation . . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  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 of Agentic AI
   use cases.  These includes provisioning, registration, cross-domain
   interconnection, and access control.  This document establishes a
   starting point to guide Agentic AI security design, development, and
   implementation consideration discussions.



Ni, et al.                 Expires 6 May 2026                   [Page 2]

Internet-Draft         agent-security-requirements         November 2025


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

                    +----------------+
                    |  Master Agent  |
                    +-^--------------+
                    +-+--------------+
                    | |  Firewall    |
                    +-+--------------+
                      |
   -------------- (2) | Inter-domain--------------
                      |
   +------------------+---------------------------------+
   |                +-+--------------+   Intra-domain   |
   |                | |  Firewall    |                  |
   |                +-+--------------+                  |
   |                +-v--------------+                  |
   |        +-------+  Master Agent  |                  |
   |   (3)  |       +----------------+                  |
   |        |                              (1)          |
   |   +----v-----+    +----------+    +----------+     |
   |   |  Agent   +---->  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 four types of security
   interactions, in a sequential order:

   1.  Provisioning and Registration: Creating agent identity,
       establishing initial trust, provisioning agent secrets and
       credentials.

   2.  Cross-domain Interconnection: Enabling secure, authenticated
       communication between agents across different trust domains.





Ni, et al.                 Expires 6 May 2026                   [Page 3]

Internet-Draft         agent-security-requirements         November 2025


   3.  Access Control: The Master Agent validates both intra-domain and
       inter-domain access tokens, creates internal workflow 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.

3.  Provisioning and Registration

   Figure 2 shows the diagram of provisioning and registration, which
   includes Agent Certificate Authority(ACA) and Agent Registry
   Service(ARS):

   1.  ACA (Agent Certificate Authority): A trusted third party that
       issues and manages credentials for agents.

   2.  ARS (Agent Registry Service): A system responsible for agent
       identity registration and discovery-matching.



















Ni, et al.                 Expires 6 May 2026                   [Page 4]

Internet-Draft         agent-security-requirements         November 2025


   +-------------------------------------------+
   |                                           |
   | +-----------------+  +------------------+ |
   | |Agent Certificate|  |  Agent Registry  | |
   | |Authority(ACA)   |  |  Service(ARS)    | |
   | +--------^--------+  +---------^--------+ |
   |          |                     |          |
   |         ++---------------------++         |
   |         ||     +----------+    ||         |
   |         |+----->   Agent  +----+|         |
   |         |      +----------+     |         |
   |         |                       |         |
   |         |   device/container    |         |
   |         +-----------------------+         |
   |                                           |
   +-------------------------------------------+

   _Figure 2.  Diagram for Provisioning and Registration_

3.1.  Identity Provisioning and Management

   Identity provisioning and management are the process of creating and
   assigning a verifiable digital identity to an agent.

   *  Initial Trust Establishment: Intial trust can be established
      through one or more of the following trust anchors, including, but
      are 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, such as a Certificate
      Signing Request or a Proof of Possession by signing with the
      corresponding private key, as well as remote attestation by
      collecting and submitting evidence to a RATS (Remote Attestation
      Procedures) Verifier.  Additionally, to define the agent's
      operational scope, the request should incorporate user identity
      context, binding the credential to a specific human user or an
      organizational role.







Ni, et al.                 Expires 6 May 2026                   [Page 5]

Internet-Draft         agent-security-requirements         November 2025


   *  Credential Issuarance: 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 Mangement: 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 a key rotation.

3.2.  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: This step automatically removes expired
      credentials and synchronizes with the ACA to ensure timely
      revocation of credentials, preventing the use of invalid or
      compromised credentials.

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

4.  Cross-Domain Interconnection

4.1.  Cross-Domain Identifier Interoperability

   Different domains may use distinct identifier schemas.  Possible
   methods include:

   *  pre-configured schema translation



Ni, et al.                 Expires 6 May 2026                   [Page 6]

Internet-Draft         agent-security-requirements         November 2025


   *  cross-domain identifier synchronization

   *  a universal parsing framework or system

4.2.  Secure Cross-Domain Transmission

   Mutual TLS (mTLS) connection starts from the external requesting
   agent to the master agent.  The master agent terminates the mTLS
   connection and parses the application layer requests.  In this case,
   the master agent functions as an OAuth resource server, and manages
   internal task orchestration.

4.3.  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
      Grant[I-D.draft-ietf-oauth-identity-chaining-06])

   which can even be combined with 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

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

5.  Access Control






Ni, et al.                 Expires 6 May 2026                   [Page 7]

Internet-Draft         agent-security-requirements         November 2025


5.1.  Authorization Handling

   The master agent acts as the role of OAuth 2.1 resource server.  It
   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.

5.2.  Authorization Chaining Across Domains

   In an agentic AI use case, a request may traverse multiple resource
   servers in multiple trust domains before completing.  It will be
   common that the requesting agent from domain A needs to access the
   resource server (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

   The current best practice is
   [I-D.draft-ietf-oauth-identity-chaining-06].

5.3.  Converting to Internal Workflow

   *  Workflow Generation: Complex tasks often require multi-agent
      collaboration.  The master agent receives, parses, and extracts
      the original job request from the external requesting agent, then
      create sequential workflows or parallel calls.  This requires the
      master agent to have information of all callable internal API
      assets, agent capabilities, etc.

   *  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
      current least privilege best practice of downscoping-Transaction
      Tokens as specified in
      [I-D.draft-tulshibagwale-oauth-transaction-tokens-05].  The access
      rights to each downstream workload decrease.



Ni, et al.                 Expires 6 May 2026                   [Page 8]

Internet-Draft         agent-security-requirements         November 2025


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

   *  bearer tokens

   *  API keys

   *  pre-shared secrets

   *  username-passwords

   *  X.509 certificates, etc.

   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 (bearer tokens)

5.5.  Zero Trust Analysis

   The above information can be used as rich context that allow zero
   trust access control.  Remote attestation results of the requesting
   agent could also be part of access policy decision point's inputs.
   Remote attestation results of the requesting agent could include the
   following information:

   *  RoT and trust anchors

   *  Identifiers

   *  Affiliations

   *  Posture assessment results

   *  Capabilities

   The overall information will be used as input of Policy Engine (PE)
   and Policy Decision Point (PDP).



Ni, et al.                 Expires 6 May 2026                   [Page 9]

Internet-Draft         agent-security-requirements         November 2025


5.6.  Microsegmentation

   Microsegmentation may be enforced to prevent lateral movement of
   security risks.  Possible granularity of microsegmentation includes:

   *  per IP segment/subnet

   *  per each workload

   *  per tags and attributes (of workload), etc.

   There should be policy enforcement points (PEP) at the perimeter of
   each segment.  Each PEP can receive software-defined security
   policies issued by PE/PDP.

6.  IANA Considerations

   This document has no IANA actions.

7.  References

7.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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

7.2.  Informative References

   [I-D.draft-ietf-oauth-identity-chaining-06]
              Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins,
              M. J., and B. Campbell, "OAuth Identity and Authorization
              Chaining Across Domains", Work in Progress, Internet-
              Draft, draft-ietf-oauth-identity-chaining-06, 12 September
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              oauth-identity-chaining-06>.

   [I-D.draft-tulshibagwale-oauth-transaction-tokens-05]
              Tulshibagwale, A., Fletcher, G., and P. Kasselman,
              "Transaction Tokens", Work in Progress, Internet-Draft,
              draft-tulshibagwale-oauth-transaction-tokens-05, 20
              October 2023, <https://datatracker.ietf.org/doc/html/
              draft-tulshibagwale-oauth-transaction-tokens-05>.



Ni, et al.                 Expires 6 May 2026                  [Page 10]

Internet-Draft         agent-security-requirements         November 2025


Acknowledgments

   TODO acknowledge.

Authors' Addresses

   Yuan Ni
   Huawei
   Email: niyuan1@huawei.com


   Chunchi Peter Liu
   Huawei
   Email: liuchunchi@huawei.com


   Nan Geng
   Huawei
   Email: gengnan@huawei.com


   Qiangzhou Gao
   Huawei
   Email: gaoqiangzhou@huawei.com


   Zhenbin Robin Li
   Huawei
   Email: robinli314@163.com






















Ni, et al.                 Expires 6 May 2026                  [Page 11]
