Who Are the Robots? Uncovering AI Agents Identities

Who Are the Robots? Uncovering AI Agents Identities

Speakers: Ron Popov (Security Researcher, Tennable), Clément Notin (Security Researcher, Tennable)

Conference: fwd:cloudsec

YouTube: https://www.youtube.com/watch?v=mMxACHKIAwY

Overview

In an era where Artificial Intelligence (AI) agents are rapidly integrating into enterprise operations, the critical challenge of securing these autonomous entities remains largely unaddressed. Ron Popov and Clément Notin, security researchers at Tennable, delivered a compelling talk at fwd:cloudsec, shedding light on the nascent but vital field of AI agent identity management. Their presentation, "Who Are the Robots? Uncovering AI Agents Identities," delved into the distinct approaches taken by Microsoft and Google to establish identity solutions for AI agents, a fundamental component of their secure operation.

The speakers highlighted that while identity has always been paramount in security—touching upon authentication, authorization, and permission management—AI agents introduce unique complexities due to their non-deterministic and creative nature. Microsoft's Entra Agent ID and Google's Agent Identities represent early, yet distinct, attempts to provide structured identity frameworks for these intelligent software entities. Popov and Notin meticulously analyzed the design choices, architectural implications, and security trade-offs of each model, offering crucial insights for organizations navigating the uncharted waters of AI security.

This article aims to unpack the technical intricacies presented by Popov and Notin, exploring why dedicated identity solutions for AI agents are necessary, how Microsoft and Google have engineered their respective offerings, and what defensive strategies security practitioners should adopt. The discussion underscores the urgent need for robust identity management to ensure the secure, auditable, and controlled deployment of AI agents across cloud environments, ultimately empowering organizations to confidently integrate AI into their critical workflows.

Background

▶ Watch: Microsoft/GCP introduce dedicated AI agent identity solutions (0:30)

The proliferation of AI agents—software entities leveraging Large Language Models (LLMs) for reasoning and decision-making—is transforming various industries. These agents are typically connected to external resources like tools for action execution and knowledge bases for contextual information, often possessing memory mechanisms for persistent state. As they become more sophisticated and autonomous, securing them presents novel challenges, particularly concerning identity management.

Historically, identity security distinguishes between human identities (for individuals) and non-human identities (NHIs), which typically encompass service accounts, managed identities, and application registrations. While AI agents are unequivocally non-human, Microsoft and Google have opted to develop dedicated "agentic AI identity models" rather than simply re-purposing existing NHI frameworks. This deliberate choice stems from the unique characteristics of AI agents:

1. Non-determinism: Unlike traditional scripts or programs, AI agents exhibit creative, unexpected, and often unpredictable behaviors. They can reason, find novel solutions, and adapt dynamically, making their actions harder to baseline and control with conventional identity policies.
2. Authentication and Authorization Challenges: Managing numerous agents with diverse access requirements necessitates robust and secure credential management. Balancing the principle of least privilege with the need for agents to maintain creativity and problem-solving autonomy is a delicate act. Over-restricting an agent can reduce it to a "glorified script," negating its core value.
3. Dedicated Inventory: The anticipated scale of AI agent deployment demands a specialized inventory system to track and manage these entities effectively.
4. Auditing Requirements: Beyond merely logging "who did what," auditing AI agents requires understanding "why" an action was performed. Linking agent actions to their underlying reasoning process is crucial for accountability and incident response.
5. Risk Detection: The unpredictable nature of agents makes traditional behavioral baselining ineffective for anomaly detection. New methodologies are required to fine-tune algorithms for identifying risky or malicious agent behaviors.

Microsoft's Entra Agent ID and Google's Agent Identities emerged approximately a year prior to the talk, both addressing these challenges. Notably, AWS had not announced a dedicated AI agent identity solution at the time, indicating a varied industry response to this emerging security domain. The speakers focused on agents running within cloud providers, acknowledging the existence of unmanaged agents but prioritizing the managed cloud-native solutions for their analysis.

Key Findings

▶ Watch: Why dedicated AI agent identity models are essential (3:40)

Popov and Notin's research revealed two fundamentally different philosophies in designing AI agent identity solutions, each with distinct strengths and weaknesses:

1. Microsoft Entra Agent ID: The IDP-Centric, Comprehensive, Cross-Platform Model.

• Integration with Identity Provider (IDP): Microsoft's solution is built directly on Entra ID (formerly Azure Active Directory), leveraging an existing, mature identity management platform. This positions Entra Agent ID as a universal identity solution compatible with various AI platforms, including Microsoft's own (Copilot, Microsoft Foundry) and third-party agents, even if not hosted on Azure.
• Granular Control and Complexity: The model introduces a sophisticated hierarchy of four object types (Blueprint, Blueprint Principle, Agent Identity, Agent User) and allows for fine-grained permission assignment at different levels. This complexity enables rich authentication flows (interactive, autonomous, digital colleague) and detailed traceability, particularly when agents act "on behalf of" human users.
• Supply Chain Risk: The cross-tenant instantiation of a Blueprint Principle introduces a supply chain trust model, where customers must implicitly trust the Managed Security Service Provider (MSSP) deploying the agent.

1. Google Agent Identities: The Cloud-Centric, Hardened, Developer-Friendly Model.

• Integration with Cloud Provider: Google's solution is deeply embedded within GCP, making it primarily applicable to AI agents running inside GCP services. This design prioritizes hardening access tokens and leveraging cloud-native security features.
• Simplified Developer Experience: From a developer's perspective, creating an agent automatically provisions an associated identity, simplifying the identity management overhead and reducing the likelihood of security misconfigurations.
• Enhanced Token Security with Spiffy: Google employs Spiffy (Secure Production Identity Framework for Everyone), an open-source identity framework, to provide additional authentication and ensure certificant-bound access tokens. This "double verification" mechanism significantly enhances the security of access tokens, mitigating risks associated with token leakage.
• Visibility Gaps: The GCP-centric nature means that agents running on non-GCP AI services (e.g., Gemini enterprise business) or unmanaged agents do not benefit from this identity solution, leading to potential visibility gaps across an organization's AI ecosystem.

Overall Recommendations from Speakers:

• IDP-Centricity: Agent identity solutions should ideally be part of an organization's core IDP, as identity management is the natural domain for such solutions.
• Support for Unmanaged Agents: To ensure comprehensive visibility, identity solutions must extend to unmanaged AI agents, not just those hosted within a specific cloud provider.
• Blueprint Model Advantages: The blueprint approach, particularly for pre-requesting and managing permissions, offers significant security and operational benefits by simplifying initial onboarding and drift monitoring.

The speakers concluded by emphasizing that visibility and inventory are the foundational steps for AI agent security. Organizations must inventory their agents and understand the specific identity models in use to make informed decisions about security posture.

Technical Deep Dive

▶ Watch: Introducing Microsoft Entra Agent ID model (5:30)

The core of the talk involved a detailed examination of Microsoft's Entra Agent ID and Google's Agent Identities, highlighting their architectural nuances and security implications.

Microsoft Entra Agent ID

Microsoft's Entra Agent ID is designed as a comprehensive identity solution for AI agents, built upon the existing Entra ID (formerly Azure Active Directory) platform. This foundational choice allows it to inherit the robust identity management capabilities of Entra ID and positions it as a universal identity platform for AI agents, irrespective of their hosting environment. It is compatible with Microsoft's own AI platforms like Copilot and Microsoft Foundry, as well as third-party AI agents, even if they are not hosted on Azure.

The model revolves around four primary object types:

1. Blueprint: This is the central repository for an agent's settings and management configurations. It defines the agent's fundamental characteristics and operational parameters.
2. Blueprint Principle: When an agent blueprint is deployed into a customer's tenant (e.g., from an MSSP tenant to a customer tenant), it is instantiated as a Blueprint Principle. This object represents the identity of the blueprint within the customer's Entra tenant. A critical aspect here is that this process crosses tenant isolation boundaries, introducing a supply chain attack risk. The customer must explicitly trust the MSSP or vendor providing the blueprint due to the permissions and capabilities granted to this principle. Its primary role is to create Agent Identities.
3. Agent Identity: This is the most crucial object type, representing the actual identity that the AI agent uses for its day-to-day operations. This identity is used whether the agent acts autonomously or on behalf of a human user.
4. Agent User: This is an optional object type, created when an AI agent requires human-like capabilities, such as having a mailbox, sending emails, or joining Microsoft Teams channels. An Agent User appears as a regular user in Entra ID but is labeled with information linking it back to its corresponding Agent Identity.

Authentication and Permissions:

Credentials for the agent are defined and assigned exclusively at the Blueprint level within the MSSP's tenant. This means that only the MSSP has the ability to authenticate as the agent. Entra Agent ID supports the three classic Entra ID credential types: key credentials, client credentials, and federated credentials.

Permissions can be assigned at two levels:

• Blueprint Principle Level: Permissions assigned here cascade down to all associated Agent Identities. This is where broad permissions required by all agent instances (e.g., "read security alerts," "gather tenant information") are granted.
• Agent Identity Level: Specific, granular permissions can be assigned directly to individual Agent Identities. This allows for fine-tuned access control, such as granting "read-only" access to agents operating in sensitive environments (e.g., a finance subscription), even if the blueprint has broader permissions. Both Entra roles and Azure roles can be assigned. When viewing an Agent Identity's permissions, both inherited and directly granted permissions are visible, making comprehensive auditing potentially complex.

Authentication Flows:

Entra Agent ID supports three distinct authentication flows:

1. Interactive Agents: The agent operates "on behalf of" a human user (e.g., a SOC analyst). This flow involves both the agent's identity and the human user's identity, providing enhanced traceability in logs (e.g., "agent X did Y on behalf of user Z").
2. Autonomous Agents: The agent operates independently, using only its own Agent Identity to perform tasks (e.g., gathering tenant information).
3. Digital Colleague: The agent leverages its Agent User object to interact with humans via email or Teams, mimicking a human colleague.

The model, while complex, provides extensive control and visibility into agent actions, particularly the "on behalf of" functionality, which is a significant differentiator for auditing and authorization.

Google Agent Identities

Google's Agent Identities solution takes a different approach, tightly integrated within GCP rather than an overarching IDP. This design choice primarily aims to harden the identities of AI agents running inside GCP. Consequently, it does not support "unmanaged agents" or agents running on non-GCP AI services, such as Gemini Enterprise Business, leading to potential visibility gaps across an organization's broader AI estate.

From a developer's perspective, Google's model is notably simpler: developers primarily focus on creating an agent, and the associated identity is automatically provisioned and utilized. This abstraction reduces the burden on developers and minimizes the risk of security misconfigurations.

A key component of Google's security architecture for Agent Identities is the use of Spiffy (Secure Production Identity Framework for Everyone). Spiffy is a mature, open-source identity framework that provides additional authentication on top of existing GCP authentication mechanisms. The process works as follows:

1. An agent proves to the Spiffy server that it is a legitimate AI agent running within GCP runtimes by sending telemetry about itself and its host.
2. Upon verification, the Spiffy server issues the agent an X509 certificate. This certificate is cryptographically linked to a very specific GCP access token.

All AI agent interactions, including user-to-agent and agent-to-resource communications, are routed through Agent Gateways. These gateways act as networking proxies and enforce critical security policies:

• MTLS (Mutual Transport Layer Security): The Agent Gateway enforces MTLS, ensuring that both the agent verifies the server and the server verifies the agent, establishing mutual trust.
• Context-Aware Access: This is where Spiffy's certificates come into play. The Agent Gateway enforces that the agent uses certificant-bound access tokens. This means that for an agent to access GCP services (e.g., BigQuery), it must simultaneously present a valid GCP access token AND the specific X509 certificate that the token is bound to.

The overall access flow for a GCP service involves:

1. The agent obtains a certificant-bound GCP access token from the IMDS (Instance Metadata Service) server.
2. Concurrently, the agent obtains its X509 certificate from the Spiffy server.
3. The agent then sends both the certificate and the access token to the Agent Gateway.
4. The Agent Gateway verifies the validity and matching of both credentials. Only if both are valid and linked does the gateway forward the request to the target GCP service.

This "double verification" mechanism significantly enhances the security of access tokens, providing a strong defense against token leakage, a known vulnerability in AI agent deployments. However, the limitation to GCP-hosted agents remains a significant concern for comprehensive visibility.

Demo / Proof of Concept

▶ Watch: Entra Agent ID's 'Blueprint' object explained (7:00)

The talk focused on a detailed conceptual and architectural analysis of Microsoft's Entra Agent ID and Google's Agent Identities. While the speakers provided clear examples and scenarios to illustrate the functionality and implications of each model, they did not present a live demonstration or a proof of concept exploit during the session. Their objective was to educate the audience on the design choices and security considerations of these emerging identity frameworks.

Defensive Implications

▶ Watch: Handling multi-scope identity with Blueprint Principle (8:00)

Understanding the nuances of AI agent identity solutions from Microsoft and Google is paramount for security practitioners seeking to govern and protect their AI deployments. The talk highlighted several critical defensive implications:

1. Inventory Your AI Agents: The foundational step for AI agent security is comprehensive inventory and visibility. Organizations must identify all AI agents operating within their environment, whether managed by cloud providers or unmanaged. Both Microsoft and Google offer tools to list agent identities within their ecosystems; these should be leveraged without hesitation. Without a clear inventory, effective security posture management is impossible.
2. Strategic Model Selection (Visibility vs. Hardening): Organizations must critically assess their priorities. If an organization is just beginning its AI security journey, good visibility across all agent types (managed and unmanaged) might be more crucial. This would favor solutions that integrate with a central IDP and support unmanaged agents. For organizations already mature in AI security and heavily invested in a specific cloud ecosystem, hardening access tokens and leveraging advanced features like certificant-bound tokens might take precedence.
3. Advocate for IDP-Centric Solutions: The speakers strongly advocated for AI agent identity solutions to be integrated within an organization's Identity Provider (IDP). This natural fit ensures consistent identity management, centralized policy enforcement, and better visibility across the entire enterprise identity landscape. Security practitioners should actively communicate this preference to their vendors.
4. Demand Proper Agent Identities, Not Human Identities: A significant takeaway is the need to push vendors to utilize dedicated AI agent identity solutions. If a vendor's AI agent uses an Entra user (a human identity) for its operations, this is a misconfiguration that bypasses the specific security controls and auditing capabilities designed for agents. Defenders should be proactive in requesting and enforcing the use of appropriate agent identity types.
5. Monitor Blueprint Principles (Microsoft Entra Agent ID): In the Microsoft model, the Blueprint Principle is a critical object that crosses tenant boundaries and has the capability to create Agent Identities. While it should only create identities, nothing technically prevents it from being granted additional, powerful permissions. Defenders must actively monitor the activities and assigned permissions of Blueprint Principles for any deviations from expected behavior, which could indicate a supply chain compromise or misconfiguration.
6. Understand Supply Chain Trust (Microsoft Entra Agent ID): The cross-tenant nature of the Blueprint Principle means that customers are inherently trusting the MSSP or vendor who created the blueprint. This introduces a supply chain risk that must be understood and managed through appropriate vendor risk management processes.
7. Leverage Context-Aware Access and MTLS (Google Agent Identities): For GCP-hosted agents, defenders should ensure that Agent Gateways are properly configured to enforce MTLS and context-aware access using certificant-bound tokens. This significantly raises the bar for an attacker attempting to compromise or misuse an agent's identity.
8. Balance Least Privilege with Creativity: AI agents require a delicate balance in authorization. While the principle of least privilege is paramount, overly restrictive permissions can stifle an agent's non-deterministic problem-solving capabilities. Defenders need to work with AI developers to define permission sets that are granular enough for security but flexible enough to allow agents to operate effectively.
9. Enhanced Auditing for Reasoning: Beyond "who did what," future auditing capabilities for AI agents must focus on "why" an action was performed. Defenders should seek out and implement logging and monitoring solutions that can link agent actions to their underlying decision-making processes, providing crucial context for incident investigation.
10. Anticipate and Baseline the Unexpected: Due to the non-deterministic nature of AI agents, traditional behavioral baselining for risk detection is challenging. Defenders will need to explore new approaches for fine-tuning risk detection algorithms, potentially leveraging AI-powered anomaly detection tailored for agent behavior.

Key Takeaways

• Inventory and Visibility are Foundational: The first and most critical step in securing AI agents is to gain comprehensive visibility. Organizations must actively inventory all AI agents within their ecosystem, utilizing available cloud provider tools, as "you can't secure what you can't see."
• Choose Your Focus: Hardening vs. Visibility: Organizations should determine whether their immediate priority is robust token hardening (like Google's certificant-bound tokens) or broad visibility across all managed and unmanaged agents (better supported by IDP-centric solutions). This choice depends on the organization's current AI maturity and risk profile.
• Advocate for IDP-Centric Agent Identities: Security practitioners should actively push vendors to integrate AI agent identity solutions directly into core Identity Providers (IDPs). This approach naturally centralizes identity management, enhances consistency, and provides a more unified security posture than cloud-provider-specific solutions.
• Demand Dedicated Agent Identity Models: Do not accept AI agents using human identities (e.g., Entra users) for their operations. Insist that vendors implement and leverage dedicated AI agent identity models, which offer specialized security controls, auditing, and authorization mechanisms tailored to their unique non-deterministic nature.
• Leverage the Blueprint Model for Simplified Governance: Microsoft's blueprint model, allowing pre-defined permissions and centralized management, offers significant benefits for both security and operational efficiency. It simplifies initial onboarding and enables easier monitoring for permission drift, making agent governance more manageable.

About the Speaker(s)

Ron Popov is a Security Researcher at Tennable, where his expertise primarily lies in cloud and AI security. His work focuses on identifying and analyzing emerging threats and security challenges within these rapidly evolving domains.

Clément Notin is also a Security Researcher at Tennable, specializing in identity security. His extensive background covers both on-premises identity solutions, particularly with Active Directory, and cloud identity platforms, including Entra ID (formerly Azure Active Directory) and Okta. This presentation marked Clément's first appearance at the fwd:cloudsec conference.