Securing Agents using the Entra Platform

By Rojan Koc, Cloud Security Architect (Note that this is purely written and designed with my own personal perspective and does not represent the views, policies, or official position of my employer or any affiliated organization.)

As AI systems take on increasingly autonomous and user-delegated responsibilities, the identities representing those agents, Microsoft Entra Agent IDs - become integral components of the enterprise identity fabric that covers both Human and Non-Human Identities. Agent IDs authenticate to resources, hold permissions, execute workflows, and may act on behalf of users or systems or perform tasks totally anonymous. Because they operate as first-class identities, they must be governed with the same guardrails as human and workload identities.

Microsoft Entra Agent ID and Agent ID Blueprints provide a security and governance model purpose-built for managing agent identities at scale. The following guidance and Diagram represents the end-to-end lifecycle and security flow for an Agent ID within Microsoft Entra ID on what is actually supported as of today. It shows how an Agent ID is created, governed, authenticated, evaluated for risk, and monitored across the Entra platform.

Prefer Strong, Non-Human Credential Strategies for Agent IDs

Microsoft Entra Agent ID supports secure, non-human credential models appropriate for autonomous or semi-autonomous agents. Supported credential types include:

• Managed identity–based authentication (when the agent runs on Azure or supported environments).
• Federated identity credentials, using trusted external identity providers without storing secrets.
• Certificates and cryptographic keys.
• Client secrets, which are supported but should be used only when strictly necessary.

Microsoft explicitly discourages long-lived secrets. Secrets if used must be tightly governed, short-lived, and rotated frequently.

Establish Agent ID Blueprint Categories for Consistent Governance

Agent ID Blueprints define the expected security baseline and metadata for every Agent ID created from them. Blueprints ensure that each Agent ID receives:

• Required governance metadata (owner, sponsor, description).
• Prescribed authentication methods (e.g., certificate vs. federated credential).
• Baseline Conditional Access (CA) applicability.
• Defined scope and operational boundaries.

Supported blueprint elements include:

• Blueprint type and description
• Required custom security attributes
• Required authentication/credential method types
• Required ownership metadata
• Lifecycle governance requirements

Blueprints help ensure uniform onboarding and governance before the agent requests for a bearer token to access the resource server.

Use the Agent Registry for Discovery and Governance

All Agent IDs appear in the Agent Registry, a dedicated catalog within Microsoft Entra that provides:

• Central discovery of all registered agents
• Visibility into agent metadata
• Integration with governance and monitoring capabilities

The registry improves transparency by treating agents as structured, governable identities rather than ad-hoc workload accounts, without an parent identity which the "Blueprint principal" acts as.

Agent Collection as part of the Agent Registry provides you an overview of Global (Allowed Agents) and Quarantined (Disallowed agents) which in the essence depict if an Agent is exposed to the end-user or not.

Govern Agent IDs with Entra Identity Governance

Agent IDs can be governed and controlled by Microsoft Entra Identity Governance capabilities besides being added to a Registry:

• Entitlement Management (for controlled access fulfillment process)
• Lifecycle workflows to onboard, update, or retire Agent IDs based on the semantics & updates of the "sponsor" which are responsible for overseeing and managing the JML and Access Provisioning of the Agent ID it self.
• Access Reviews, allowing periodic verification of permissions and ownership
• Ownership requirements, ensuring every agent identity has a maintained responsible party - This can be an Owner or a Sponsor.

Key governance goals include:

• Avoiding orphaned agent identities
• Detecting unused or overly privileged Agent ID's.
• Ensuring permissions match agent purpose following least privilege principle.

Use Identity Protection and CA for Risky Agents

Microsoft Entra Identity Protection extends its threat detection model to risky agents, providing:

• Detection of anomalous or high-risk agent activity
• Real-time risk evaluation that can be consumed by Conditional Access
• Allowed authentication methods (e.g., certificate-based, federated credentials, managed identity)
• Custom security attributes (commonly added through Agent ID Blueprints)
• Risk signals from Identity Protection for Agent IDs

Supported signals focus on behavioral anomalies and misuse patterns—not user-centric signals like password spray or sign-in behavior.

Expand Logging and Monitoring for Agent ID Activity

Microsoft supports full audit and monitoring visibility for Agent IDs through:

• Sign-in logs
• Audit logs
• Forwarding all logs to SIEM platforms such as Microsoft Sentinel

KQL to detect OAuth Permissions Grant & PIM Assignments for Agents (Feel free to modify or adjust it to meet your needs)

AuditLogs 
| where TimeGenerated >= ago(365d) 
| where OperationName in~ ( 
"Add OAuth2PermissionGrant", 
"Add v2 application permissions", 
"Add app role assignment to service principal") 
| extend ActorUPN = tostring(InitiatedBy.user.userPrincipalName), ActorApp = tostring(InitiatedBy.app.displayName), 
SpId = tostring(TargetResources[0].id), 
SpDisplayName = tostring(TargetResources[0].displayName), 
AppType = tostring(TargetResources[0].type) 
| where SpDisplayName has_any ("agent", "ai", "gpt", "copilot", "assistant") or ActorApp has_any ("agent", "ai", "gpt", "copilot", "assistant") 
| project TimeGenerated, OperationName, SpDisplayName, ActorApp 
| order by TimeGenerated desc        

This query detects when AI or agent-type service principals receive new OAuth API permissions. It analyzes the past 365 days of AuditLogs for operations that add OAuth permissions or app roles, including the type of permission or role granted and which agent identity was involved. I recommend using App Governance in Microsoft Defender for Cloud Apps (MCAS) to detect risky, high-impact, or unused critical permissions and to build a periodic operational review-cycle to mitigate these findings and assess their impact.