WIMSE Applicability for AI Agents

4.1.1. Network Access Control in Campus

Campus administrators require authentication of agents before granting access to an internal network via authentication protocols such as IEEE 802.1X (e.g., using EAP-TLS). In this scenario, the Authentication Server must verify the agent's credential and determine its network privileges. A single-identity credential only allows the Authentication Server to identify the agent itself. It does not directly provide information about the user or organization accountable for the agent. Without further information, Authentication Server may treat the agent as a guest, providing only limited public access or rejecting the request to protect sensitive zones.¶

A dual-identity credential allows the Authentication Server to verify both the agent's identity and the identity of the accountable user or organization associated with the agent. For instance, an agent associated with Alice from the R&D department can be identified as a trusted entity, and can receive proper access privileges according to existing IAM information (like RBAC). This enables the network to implement user-specific segmentation, such as automatically assigning the agent to the R&D VLAN rather than a guest network.¶

4.1.2. Cross-organization Interaction

In collaborative enterprise environments, it is essential to ensure that an agent can be associated with an identifiable organization that is accountable for its operation. This requirement spans the entire credential lifecycle, from issuance to interaction.¶

• Issuance: When an agent requests an identity credential, the identity server may require organizational oversight. By requiring the accountable organization to approve the credential request, the server can establish a cryptographically verifiable relationship between the agent identity and the accountable organization before issuing the credential.¶

• Interaction: When an agent accesses another agent or a service across organizational boundaries, a dual-identity credential allows the receiving entity to identify both the agent and the organization accountable for it, providing stronger accountability and traceability for cross-organization interactions.¶

4.2.1. Agent-Mediated (Owner-Pre-Signed)

In this model, the owner acts as a local offline approver, countersigning the agent's request before it is submitted to the proxy. The identity binding phase, consisting of the following two steps, is added prior to the standard issuance flow defined in Figure 1:¶

a. The agent generates and signs an identity credential request and sends it to the owner.¶

b. The owner reviews and countersigns the request and returns the countersigned request to the agent.¶

The following steps are similar to the basic architecture, that is, the agent sends the countersigned request to the server via the proxy (steps 1 and 2), then the server verifies both signatures and issues the dual-identity credential to the agent via the proxy (steps 3 and 4).¶

  +----------------------------+
  |       Identity Server      |
  +-------------- ^ + ---------+
               (2)| |(3)
+-----------------+-+---------------------------------+
| Trust Domain    | |              +-------+          |
|                 | |              | owner |          |
|                 | |              +--^-+--+          |
|                 | |       (a)request| |(b)signature |
| +--------------++ v -------+ (1) +--+-v--+          |
| |              |           ------+       |          |
| |Identity Proxy| Agent API ------> Agent |          |
| |              |           | (4) |       |          |
| +--------------+-----------+     +-------+          |
+-----------------------------------------------------+

Figure 2: Agent-Mediated Model¶

• Typical Application Scenarios: This model is ideal for local identity binding where the owner and agent operate on the same host. It supports asynchronous and offline owner confirmation, allowing the owner to use a local signing module (e.g., a hardware security key) to countersign the agent's request. For instance, a developer may use a personal hardware security key to countersign an agent's request directly on their local machine. Therefore, this model supports hardware-based identity binding, cryptographically anchoring the agent’s dual-identity to the specific physical device managed by the owner.¶

• Attack Surface: The primary attack surface lies in the local environment, focusing on two main risks. The first is human-agent trust exploitation: an attacked or rogue agent may manipulate human users to approve a malicious request. The second is the compromise of signing keys: if the owner’s local private keys are not protected by hardware (e.g., TPM), an attacker can forge confirmations.¶

4.2.2. Owner-Mediated (Gateway Mode)

In this model, the owner acts as the supervisory gatekeeper between the proxy and the server. It inspects requests relayed by the proxy to ensure compliance with organizational policies, providing cryptographic binding only after approval.¶

Such a mechanism is integrated into the basic architecture as shown in Figure 3. First, the agent generates and signs an identity credential request and sends it to the proxy (step 1), then：¶

a. The proxy intercepts the request and relays it to the owner for administrative inspection.¶

b. The owner reviews and countersigns the request. It then forwards the countersigned request to the server.¶

c. The server verifies both signatures and issues the dual-identity credential back to the owner, who then dispatches it to the proxy.¶

Finally, the proxy sends the credential to the corresponding agent (step 4).¶

Figure 3 shows a one-to-one mapping case between the owner and the proxy. In this case, the function of the owner can be integrated directly into the proxy, collapsing the hierarchy into a single entity to simplify the deployment. Moreover, this model also supports a one-to-many topology, allowing a central owner to manage multiple proxies across various trust domains.¶

  +----------------------------+
  |      Identity Server       |
  +------------------^-+-------+
      (b)request     | | (c)dual-identity
      (signature)    | |  credential
  +------------------+-v-------+
  |           Owner            |
  +------------------^-+-------+
      (a)request     | | (c)
+--------------------+-+--------------------------------+
| Trust Domain       | |                                |
| +--------------+---+-v-------+     (1)      +-------+ |
| |              |             <---------------       | |
| |Identity Proxy|  Agent API  |--------------> Agent | |
| |              |             |     (4)      |       | |
| +--------------+-------------+              +-------+ |
+-------------------------------------------------------+

Figure 3: Owner-Mediated Model¶

• Typical Application Scenarios: This model is ideal for enterprise governance. Since the owner sits in the middle, it acts as a gateway to ensure that no request reaches the server unless it complies with enterprise security policies and compliance requirements. It is particularly suitable for hierarchical environments where the owner acts as a centralized gateway for multiple proxies.¶

• Attack Surface: The owner becomes a high-value target and a single point of failure. If it is compromised, an attacker can forge approvals for any agent across the managed proxies. Furthermore, as a centralized gateway, the owner is vulnerable to Denial-of-Service attacks. It is essential to implement rate limiting and request queuing.¶

4.2.3. Server-Mediated (Challenge-Response)

In this model, the owner acts as an independent verifier. The server orchestrates the binding phase by contacting the owner as a separate step in the issuance logic, decoupling the binding from the agent's request.¶

This mechanism is integrated into the basic architecture as shown in Figure 4. First, the agent sends an identity credential request to the server via the proxy (steps 1 and 2), then:¶

a. The server pauses the process and sends a binding challenge to the owner accountable for the agent's operation. This initiates the owner confirmation flow.¶

b. The owner reviews the challenge, signs it, and returns the response to the server.¶

After that, the server validates the owner's response, completes the identity binding, and issues the dual-identity credential to the agent via the proxy (steps 3 and 4).¶

  +----------------------------+(a)challenge  +---- --+
  |                            +-------------->       |
  |       Identity Server      <--------------+ Owner |
  |                            |(b)signature  |       |
  +-------------- ^ +----------+              +---- --+
               (2)| |(3)
+-----------------+-+-----------------------------------+
| Trust Domain    | |                                   |
| +---------------+-v----------+     (1)      +-------+ |
| |              |             |--------------+       | |
| |Identity Proxy|  Agent API  |--------------> Agent | |
| |              |             |     (4)      |       | |
| +----------------------------+              +-------+ |
+-------------------------------------------------------+

Figure 4: Server-Mediated Model¶

• Typical Application Scenarios: This model is suitable for scenarios requiring independent and real-time confirmation from an owner who is not involved in the initial request path. For instance, an agent is hosted by a third-party service provider, while the organization providing the agent remains accountable for its operation. When the agent requests an identity credential, the server initiates an out-of-band verification directly with the administrative center.¶

• Attack Surface: The primary risk lies in the out-of-band channel. Without nonces or mutual authentication, an attacker could impersonate the owner or replay a previous confirmation response.¶