Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article provides operational best practices for designing, securing, and governing AI agent identities with Microsoft Entra Agent ID. These recommendations help you make informed decisions when planning agent deployments, managing credentials, enforcing access policies, and monitoring agent activity.
For foundational concepts, see What is Microsoft Entra Agent ID? and Key concepts.
Design agent identity blueprints
Agent identity blueprints are templates that define the security posture for all agent instances of a common kind. Thoughtful blueprint design is the foundation of well-governed agent deployments.
Plan blueprints before deploying agents. Define required settings, permissions, and metadata in the blueprint up front rather than creating ad-hoc service principals. This ensures a consistent, governed rollout across all instances. For guidance on structuring your identity model, see Plan your agent identity architecture.
Provision a unique identity per agent instance. Avoid sharing identities between different agents. Distinct identities improve traceability and let you disable or update one agent without impacting others. The blueprint model makes scaling with unique identities manageable because credentials live on the blueprint, not each instance. For instructions, see Create and delete agent identities.
Assign a sponsor and an owner at creation time. Every blueprint and agent identity must have a sponsor; the person or group accountable for the agent's purpose. Assign an owner (technical admin) as well. Periodically verify that these assignments are current, especially when personnel changes occur.
Provide descriptive metadata. Fill in the description, tags, and verified publisher fields on each blueprint to clearly document the agent's purpose, scope, and owning team. Good metadata improves discovery and helps colleagues understand the agent's role at a glance. For blueprint setup details, see Create an agent identity blueprint.
Apply policies at the blueprint level. Associate Conditional Access rules, API permissions, and governance controls with the blueprint so that all current and future agent instances inherit them automatically. Disabling a blueprint instantly blocks all its agent identities. This option provides a rapid kill-switch when needed. For details, see Conditional Access for agents.
Use the Agent ID framework for all agents. Don't create AI agents as plain app registrations or service principals outside the Agent ID framework. Always use the supported creation channels so agents are tracked as agent identities with built-in sponsor accountability and lifecycle controls.
Create agent's user accounts only when necessary. Agent's user accounts should only be created for scenarios that truly require a user object, such as an agent needing a mailbox or Teams presence. If your agent can operate with app credentials alone, avoid agent's user accounts because they add complexity with licenses, group memberships, and user-level policies.
Manage credentials securely
Credential management is critical to preventing unauthorized access through agent identities. For detailed steps, see Create an agent identity blueprint.
Use managed identities or certificates in production. For production agents, prefer federated identity credentials (managed identities) or certificates over client secrets. Managed identities eliminate stored secrets entirely. Use client secrets only for initial development or testing, and rotate them out before going live.
Isolate credentials per blueprint. Don't reuse the same credential across unrelated blueprints. If you have separate environments (dev, test, prod), use separate blueprints or environment-specific federated credentials so that a compromise in one environment doesn't affect others. For setup instructions, see Create an agent identity blueprint.
Store credentials securely. Store certificate private keys in Azure Key Vault or an HSM. If using federated credentials tied to a managed identity, limit the managed identity's scope. Establish a rotation schedule to rotate certificates at least annually even though blueprints allow long-lived credentials.
Align OAuth flows with agent scenarios. Use the appropriate OAuth flow for your agent's operating model:
- For autonomous agents with no user context, use the client credentials flow with only the required app permissions.
- For interactive agents acting on behalf of a user, use the on-behalf-of (OBO) flow so user access policies and consent apply.
- Avoid granting app permissions when delegated permissions would suffice.
Monitor token usage after deployment. Review sign-in logs to confirm agents are using the intended authentication method and credential type. Periodically audit the API permissions consented on each blueprint to prevent privilege creep.
Enforce access controls
Apply the same Zero Trust principles to agent identities as you do to user identities. For detailed configuration, see Conditional Access for agents and Identity Protection for agents.
Segment agents with custom security attributes. Define organization-wide attributes such as
Environment,Department, orDataSensitivityand assign them to agent identities. Use these attributes in Conditional Access policy conditions to apply fine-grained controls at scale, for example, blocking non-production agents from accessing production resources. For details, see Assign custom security attributes.Block high-risk agents automatically. Deploy a Conditional Access policy that blocks agent identities flagged with high risk levels by Identity Protection. This is analogous to blocking risky users and ensures compromised agents are cut off immediately.
Create agent-specific Conditional Access policies. Don't rely on user-targeted policies for agents. Agents can't satisfy interactive controls like MFA, so create separate policies that use identity filters, risk signals, and named locations as control points. Use report-only mode to test policies before enforcing them. For step-by-step guidance, see Conditional Access for agents.
Review existing policies for agent impact. Audit broad policies (like "All users must use MFA") to ensure they don't unintentionally block agent flows. Refactor to exclude agent identities and create dedicated agent policies with appropriate controls.
Implement least-privilege permissions. Use the authorization guidance to grant only the permissions each agent needs. Don't grant broad permissions as a convenience. Limit permissions to specific scopes, API resources, or sites. Review and right-size permissions periodically.
Govern the agent lifecycle
Effective governance prevents agent sprawl and ensures agents remain accountable throughout their lifecycle. For governance tools, see Identity governance for agents and Access packages for agent identities.
Register all agents in Microsoft Entra. Register every agent, whether built in Copilot Studio, Azure, or external platforms, in Microsoft Entra through the Agent ID framework. Centralized registration eliminates shadow AI and gives IT full visibility. For supported methods, see Agent creation channels.
Standardize naming conventions. Define and enforce a naming convention for agent identities, such as prefixing display names with the department or function (for example,
Agent-HROnboardingBot). Consistent naming makes agents recognizable in logs and the admin center.Include agents in access reviews. Configure periodic access reviews that include agent identities. Have sponsors attest every 6-12 months that each agent is still needed and properly configured. If a sponsor doesn't confirm, evaluate the agent for decommissioning.
Monitor for orphaned agents. Develop a quarterly review process to identify agents with missing sponsors, outdated metadata, or no recent activity. Reassign sponsorship or decommission unused agents. For a centralized view, see View and filter agent identities.
Use access packages for standardized access. For agents with common access patterns (for example, a fleet of customer support agents), use access packages to grant time-bound, auditable access through approval workflows rather than direct permission assignments.
Monitor and audit agent activity
Continuous monitoring ensures agents operate within expected boundaries. For log details, see Sign-in and audit logs for agents.
Monitor sign-in logs for anomalies. Set up alerts for unusual patterns such as sudden spikes in token requests, access to unexpected APIs, or sign-ins from unfamiliar IP ranges. Agent sign-in logs show each token acquisition with details about the resource, credential type, and outcome.
Track configuration changes in audit logs. Monitor audit logs for changes to agent blueprints, credential additions, permission grants, and role assignments. Alert on changes that happen outside your normal deployment pipeline.
Include agents in incident response. When analyzing security incidents, check whether any agents had access to affected resources and review their activity during the incident window. Fold agent identity checks into your existing post-mortem processes.
Set up proactive alerts for:
- Credential expiration (certificates or secrets approaching their end date)
- Agent blocked by Conditional Access or Identity Protection
- Excessive failed token acquisition attempts
- Unexpected permission or role changes
Retain logs for compliance. Ensure your log retention policy covers agent activity for the duration required by your organization's compliance framework. Export high-volume agent logs to a secure archive if needed. For configuration options, see Configure diagnostic settings.
Coordinate development and IT workflows
Smooth agent deployments require alignment between developers building agents and IT administrators governing them.
Use supported creation channels. Build agents through Copilot Studio, Graph APIs, or the Agent 365 CLI rather than manual Graph calls that might miss required properties. These tools handle blueprint creation, credential binding, and instance setup automatically.
Establish a production handshake process. When a new agent moves to production, have an identity admin verify its Entra Agent ID settings: confirm the blueprint and sponsor are correct, required permissions are consented, Conditional Access policies apply, and the agent is in appropriate groups or administrative units.
Test in nonproduction environments. Use a separate development tenant or sandbox to validate agent authentication flows, Conditional Access policies, and permission configurations before deploying to production.
Treat agent configurations as code. Check blueprint definitions, permission configurations, and setup scripts into source control. This prevents configuration drift, enables peer review, and provides institutional memory for how agents are integrated with Entra ID.