]> Huawei

niyuan1@huawei.com

Huawei

liuchunchi@huawei.com

SEC Workload Identity in Multi System Environments WIMSE AI Agent Identity This document discusses WIMSE applicability to Agentic AI, so as to establish independent identities and credential management mechanisms for AI agents. About This Document Status information for this document may be found at . Discussion of this document takes place on the Workload Identity in Multi System Environments Working Group mailing list (), which is archived at . Subscribe at .

Introduction AI agents are autonomous software entities that receive an intent, process contextual information, and execute decisions at machine speed with minimal human intervention. Without appropriate guardrails, they may give rise to significant risks:

1. Blurred Network Boundaries: AI agents may operate across systems and platforms, which expands attack surface and amplifies security risks.
2. Arbitrary and Unpredictable Access Patterns: AI agents may perform unexpected actions or access sensitive resources susceptible to malicious manipulation or logical errors.
3. Lack of Accountability: Tracing an AI agent's actions is inherently difficult, leading to difficulty to detect erroneous behaviors.
4. Context Rot: A gradual degradation of their ability to maintain relevant and coherent call contexts over time. Therefore, for AI agents, the traditional perimeter-based security model has to transform into the identity-based security model, which is a prequisite to implementing precise access control and ensuring security visibility.

To realize this goal, a mechanism should be designed considering the following requirements:

1. Independent, Trustworthy Identities: AI agents should have independent and trustworthy identities and credentials, distinct from those of devices and users. This allows the AI agent to act either on its own behalf or as a delegation of a user, have its own access tokens and workflows.
2. Automated Credential Management: An automated mechanism is necessary for managing credentials with reduced validity period to minimize security exposure.
3. Minimal Privileged Access Tokens: AI agents should have task-oriented, fine-grained access tokens with short validity periods.
4. Explicit Workflows: AI agents need explicit workflow management in order to avoid random agentic access. The workflow could be long-termed and static, or could be short-termed and task-triggered, but the call context must always be visible and preserved.

This document discusses possibility of using WIMSE architecture to provide AI agent identities and credentials. It accords with the original WIMSE use case in Section 3.3.1 Bootstrapping Workload Identifiers and Credentials of . We also discuss requirements of extending WIMSE architecture to bind workload/AI agent identity to its user identity.

Conventions and Definitions 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. This document uses terms and concepts defined by WIMSE architecture. For a complete glossary please refer to .

1. Trust Domain: A logical grouping of systems that share a common set of security controls and policies. Agent credentials are issued under the authority of a trust domain.
2. AI Agent: The autonomous software entity that initiates the credential request. This document may refer to it as the "agent", but is is essentially the workload instead of the agent in the WIMSE architecture.
3. Identity Server: A trusted entity issuing agent identity and credentials. For simplicity, this document may refer to this component as the "server".
4. Identity Proxy: An intermediary component that can request, inspect, replace or augment agent identity credentials. It exposes an Agent API locally to agents. For simplicity, this document may refer to this component as the "proxy".

Architecture

Bootstrapping AI Agent Identity and Credentials This document presumes that the identity server has already been issued a signing certificate which has set keyCertSign in the key usage extension. The server and the proxy are assumed to have established a secure channel. A basic workflow is shown in Figure 1.

1. As an intermediary between the server and the agents, the proxy provides an agent API that agents can use to initiate identity credential requests.
2. The proxy forwards these requests, along with the evidence for verifing the operational status of the agent, to the server for processing.
3. The server validates the evidence received from the proxy, and issues the corresponding identity credentials.
4. Once issued, the proxy forwards the agent identity credentials.

Agent | | | | | | (4)identity | | | | +--------------+----- ^ -----+ credential +-------+ | | | | | evidence | | | | | +-----------------------+-------------------------------+ | | | Hosting Operating Systems and Hardware | | | +-------------------------------------------------------+ ]]> Figure 1: Basic Architecture and the Workflow

Attestation During the request and issuance of identity credentials, the proxy should gather attestation evidence from the operating system and hardware to verify the operational status of the agent. This information is used by a RATS Verifier (could be the server) to decide whether or not to issue the identity credential of an agent, whether it is a bootstrapping or a renewal request.

Extensions to the WIMSE Architecture-- Binding Workload/AI Agent Identity to Its User Identity AI Agent identity has the full complexity of user identity, since agents may act on behalf of human, organization, etc. Therefore, agent should have a credential that both denotes its identity and its human owner identity, which will provide convenience for future access controls. Cryptographic assurances must be provided that the user approves the credential request. Figure 2 illustrates the extended architecture, which binds user identity to agent identity. This architecture extends the basic workflow described in Section 2.2. The core process remains largely unchanged from steps 1 to 4. However, a critical enhancement is introduced between steps 2 and 3: 4.1. Upon receiving an identity credential request, the server forwards it to the user on whose behalf the requesting agent acts. This initiates the user confirmation flow. 4.2. The user validates the received information. Upon approval, the user should provide a cryptographic signature, binding the user's identity to the requested agent credential. Open Question: How can users effectively provide cryptographic signatures for agent credential requests? Is leveraging hardware security features in user devices a viable and practical approach? | | Identity Server <--------------+ user | | |(4.2)user | | +-------------- ^ +----------+confirmation &+------+ | | signature (2)identity | | (3)identity credential | | credential request & | | evidence | | +-----------------+-+-----------------------------------+ | | | Trust Domain | | | | (1)identity | | | | credential | | +--------------++ v ---------+ request +-------+ | | | | <--------------+ | | | |Identity Proxy| Agent API +--------------> Agent | | | | | | (4)identity | | | | +--------------+----- ^ -----+ credential +-------+ | | | | | evidence | | | | | +-----------------------+-------------------------------+ | | | Hosting Operating Systems and Hardware | | | +-------------------------------------------------------+ ]]> Figure 2: Extended Architecture and the Workflow

Comparison with CHEQ While both this document and CHEQ introduce a human element to enhance security, their goals and the underlying mechanisms are different. CHEQ focuses primarily on controlling the actions of AI agents. It requires user double confirmation when an AI Agent invokes an OAuth access token request, preventing possible deviation from user expectations. The purpose of this document is to provide distinct identity and credentials to AI agents, whether or not it is bound to an owner user of device's parent identity. Whether or not the agent inherits access permission privileges from its user is out of scope of this document.

Initial Trust Establishment AI agents may operate in cloud or campus. In the cloud, the initial trust establishment between the proxy and the server has already been solved by solutions like SPIRE. However, in campus scenarios, the heterogeneity and limited manageability of devices make credential provisioning challenging, complicating initial trust establishment. BRSKI provides a feasible method by introducing a cryptographically signed artifact called “voucher”. In the BRSKI flow, the proxy (acting as a BRSKI pledge) discovers the server (acting as a BRSKI registrar), initiates a TLS handshake, and sends a voucher request including its immutable manufacturer credential—the IDevID (Initial Device Identifier). The server uses this IDevID to contact the manufacturer's service (MASA). After validating the request, the MASA issues a signed voucher. The proxy then verifies the manufacturer's signature on the voucher, which securely transferring trust from the manufacturer to the local domain. This verified trust is a prerequisite for the server to issue a local domain device certificate (LDevID). This certificate enrollment step essentially follows the standard EST mechanism . However, it should be noted that BRSKI is not necessarily the only way to achieve this secure integration. The core goal is to bridge the initial trust gap. If the proxy is pre-configured with the target server's public key or certificate and can securely locate it, the standard EST protocol alone may be sufficient to establish trust and obtain the LDevID certificate. Open Question: What are the precise conditions and mechanisms for determining the use of various bootstrap methods (including but not limited to BRSKI and EST)?

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

References Normative References This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. 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. 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 CyberArk Zscaler University of Applied Sciences Bonn-Rhein-Sieg The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as a running instance of software executing for a specific purpose. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Five9 Bitwave Cisco This document proposes Confirmation with Human in the Loop (HITL) Exchange of Quotations (CHEQ). CHEQ allows humans to confirm decisions and actions proposed by AI Agents prior to those decisions being acted upon. It also allows humans to provide information required for tool invocation, without disclosing that information to the AI agent, protecting their privacy. CHEQ aims to guarantee that AI Agent hallucinations cannot result in unwanted actions by the human on whose behalf they are made. CHEQ can be integrated into protocols like the Model Context Protocol (MCP) and the Agent-to- Agent (A2A) protocols. It makes use of a signed object which can be carried in those protocols.

Acknowledgments TODO acknowledge.