Conditional Access for AI Agents: Governance of Non-Human Identities

Non-human identities: a new governance perimeter

The emergence of autonomous AI agents is fundamentally reshaping identity management strategies. For a long time, security teams focused on human users, then on workload identities — applications and services. Today, a third wave is emerging: entities capable of acting autonomously, chaining API calls, consuming cloud resources, and accessing sensitive data without direct human intervention.

These agents, bots, and orchestrators now constitute an attack surface in their own right. Treating them as second-class citizens in the Zero Trust strategy is no longer tenable. This article proposes a reference architecture for applying conditional access to non-human identities, with concrete recommendations for Identity & Access Management teams.

Enterprise identity mapping: four distinct families

Before defining policies, it is essential to understand the complete landscape of identities present in a Microsoft 365 and Azure environment. Four major categories can be distinguished:

• Human identities: end users, administrators, guest accounts — managed via Microsoft Entra ID.
• Workload identities: applications, CI/CD pipelines, backend services — represented by service principals or managed identities.
• Non-human identities: AI agents, conversational bots, autonomous orchestrators — the emerging category at the heart of this article.
• Service identities: service accounts, managed identities, service principals dedicated to specific automations.

This segmentation is not merely a matter of nomenclature. Each family exhibits distinct behavior, its own attack surface, and different control requirements. An AI agent can make decisions, invoke external tools, and modify the state of third-party systems — capabilities that a standard user account does not possess. Applying the same policies to these entities without adaptation would amount to ignoring their fundamentally different nature.

Agent context: key attributes for conditional evaluation

Classic conditional access evaluates three dimensions: user identity, device compliance, and network location. For an AI agent, this model must be enriched with a set of context-specific attributes:

Agent identity attributes

• Agent ID: unique and immutable identifier of the agent within the identity registry.
• Owner / Creator: owner or team responsible for the agent — essential for accountability.
• Purpose: declared purpose of the agent (HR data processing, log analysis, IT automation, etc.).
• Capabilities: list of tools and permissions granted to the agent.

Operational and risk attributes

• Runtime: execution environment (Azure Container Apps, Azure Functions, on-premises, etc.).
• Data Access Needs: scope of data required to accomplish the task.
• Tooling: third-party or internal tools that the agent can invoke (Graph API, Power Platform connectors, etc.).
• Risk Score: dynamically calculated risk score, accounting for recent behavior and detected anomalies.

This enriched context is the foundation material for any effective conditional access policy. Without it, the security gateway can only evaluate an anonymous identity, without understanding what it does or why.

Architecture of the conditional access policy gateway

Between the AI agent and the organization's protected resources stands a policy gateway structured in four sequential steps. This gateway constitutes the central control point for non-human identity governance.

1curl -X POST https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token \
2  -H "Content-Type: application/x-www-form-urlencoded" \
3  -d "client_id={agentClientId}" \
4  -d "client_secret={agentClientSecret}" \
5  -d "scope=https://graph.microsoft.com/.default" \
6  -d "grant_type=client_credentials"

1# Create a conditional access policy for workload identities
2$params = @{
3    displayName = "CA-AgentIA-RiskControl"
4    state = "enabled"
5    conditions = @{
6        clientAppTypes = @("all")
7        servicePrincipalRiskLevels = @("high", "medium")
8        applications = @{
9            includeApplications = @("All")
10        }
11        servicePrincipals = @{
12            includeServicePrincipals = @("All")
13            excludeServicePrincipals = @("excludedAgentGroupId")
14        }
15    }
16    grantControls = @{
17        operator = "OR"
18        builtInControls = @("block")
19    }
20}
21 
22New-MgIdentityConditionalAccessPolicy -BodyParameter $params

1// KQL query to monitor access from AI agents in Sentinel
2SigninLogs
3| where AppDisplayName startswith "Agent-"
4| where RiskLevelDuringSignIn in ("high", "medium")
5| project TimeGenerated, AppDisplayName, ResourceDisplayName, RiskLevelDuringSignIn, ConditionalAccessStatus
6| order by TimeGenerated desc

Protected resources: the scope of policy application

Conditional access policies for AI agents must cover all resources that may be reached by these autonomous entities:

• Cloud workloads: Azure virtual machines, containers (AKS), serverless functions.
• APIs and services: Microsoft Graph API, internal APIs exposed via Azure API Management, partner services.
• Data sources: SQL/NoSQL databases, Azure Data Lake, Azure Blob Storage.
• Tools and platforms: SaaS connectors, DevOps pipelines, automation platforms (Power Automate).
• AI and analytics services: Azure OpenAI Service, Azure Machine Learning, Azure Cognitive Services.

Three operational pillars for effective governance

1. Identity Inventory (Identity Inventory)

Impossible to secure what you don't know. Inventory is the absolute foundation of any AI agent governance strategy. This involves:

• Discovering all deployed agents, whether developed internally or from third-party solutions.
• Mapping their access paths: which APIs do they call? Which data do they read?
• Identifying their owners and responsible teams.
• Maintaining this inventory up to date via automated processes (regular scanning of service principals in Entra ID).

1# List all active service principals in Entra ID (candidate agents for inventory)
2Get-MgServicePrincipal -All | Where-Object { $_.AppRoles.Count -gt 0 } |
3  Select-Object DisplayName, AppId, CreatedDateTime |
4  Export-Csv -Path "agent-inventory.csv" -NoTypeInformation

2. Runtime Attestation (Runtime Attestation)

An AI agent doesn't have a device in the traditional sense — impossible to verify its Intune compliance. However, its execution environment can and must be attested:

• Validate that the runtime (container, function, virtual machine) meets defined security standards.
• Use mechanisms like Azure Confidential Computing or workload identity attestations to guarantee environment integrity.
• Block any access from unattested or unrecognized environments.

Reference: Azure Attestation Service

3. Policy Drift Control (Policy Drift Control)

AI agents evolve: new capabilities are regularly attributed to them, new tools connected. Each extension of an agent's scope must automatically trigger a governance review:

• Implement alerts on role or permission modifications for service principals.
• Integrate agent access review into Entra ID Access Reviews cycles.
• Document each capability change with its business justification.

Reference: Entra ID Access Reviews

Comparison: user conditional access vs AI agent

Integration into a global Zero Trust strategy

AI agents should not be governed in isolation. Their integration into the organization's Zero Trust strategy relies on the same fundamental principles — verify explicitly, apply least privilege, assume compromise — but with controls adapted to their non-human nature.

Within the Microsoft 365 and Azure ecosystem, several services directly contribute to this governance:

• Microsoft Entra ID: identity registry, conditional access, Access Reviews.
• Microsoft Sentinel: behavioral anomaly detection, log correlation.
• Microsoft Defender for Cloud: workload and runtime protection.
• Azure API Management: governance and throttling of agent API calls.
• Microsoft Purview: classification and protection of data accessed by agents.

Conclusion: inventory as an inescapable foundation

Governance of autonomous AI agents is not an incremental evolution of traditional IAM — it is a paradigm shift. These entities act, decide, and access sensitive resources at a scale and speed that manual processes cannot follow.

The message is clear: identity inventory is the non-negotiable starting point. Without comprehensive knowledge of deployed agents, their owners, their purposes, and their access paths, no conditional access policy can be effective.

As autonomous agents proliferate across Microsoft 365, Azure, and Power Platform environments, integrating non-human identities into the Zero Trust strategy is no longer a future project — it is a governance obligation to address today.