How to Audit Who Can Create Microsoft Entra Agents Before the Permission Change

What the permission change means

An agent identity blueprint is a template used to create agent identities. Microsoft documents that blueprint owners and blueprint-principal owners can create identities for that blueprint, and that AgentIdentity.CreateAsManager enables a blueprint to create agent identities in the tenant.

Treat every blueprint as a provisioning authority. Before changing permissions, answer:

• Who owns the blueprint?
• Who sponsors it?
• Which service or pipeline uses it?
• What permissions can identities created from it inherit?
• Is the blueprint still needed?

Do not begin by deleting permissions. Start with an inventory and an owner-confirmed decision for every blueprint.

Use the least privilege that fits

Use the least-privileged role that can complete the review. Microsoft documents AI Admin, Global Admin, and Global Reader as relevant Microsoft 365 administration roles. For Microsoft Entra Agent ID operations, Microsoft documents Agent ID Developer and Agent ID Administrator roles for blueprint creation and configuration.

Record the administrator account used for the audit and keep the review evidence in your normal change-management system.

Separate user access from blueprint authority

In the Microsoft 365 admin center:

1. Open Copilot or Agents settings.
2. Review User access for agents and plugins.
3. Review who can create, share, publish, and install agents.
4. Check whether access is granted to everyone, no one, or a specific group.
5. Export or record the current settings before changing them.

User access to Copilot agents is not the same control as Entra Agent ID blueprint permission. Track both layers in the audit.

Build an owner-approved register

In the Microsoft Entra admin center, open Entra ID → Agents → Agent blueprints.

For every blueprint, record:

Field	What to capture
Display name	Human-readable blueprint name
Application ID	Stable identifier for the blueprint
Owners	Users or service principals able to manage it
Sponsors	Accountable business or technical owner
Credentials	Secret, certificate, or federated credential type
Required resource access	APIs and permissions requested by the blueprint
Inheritable permissions	Resource permissions passed to created identities
Last activity	Most recent creation or administrative activity
Business purpose	What the blueprint is used for
Decision	Retain, restrict, replace, or retire

A blueprint without a current owner or sponsor is an exception, not an automatically trusted production component.

Make accountability explicit

Microsoft requires a sponsor for an agent identity blueprint. Owners manage the blueprint; sponsors provide accountability for why it exists and who is responsible for it.

For each blueprint:

1. Verify that every owner is still employed and assigned to the correct team.
2. Replace personal ownership with a controlled administrative group where appropriate.
3. Confirm that the sponsor understands the agent's data access and operating scope.
4. Remove stale owners and sponsors through your normal approval process.
5. Require a named backup owner for production blueprints.

Avoid using a shared administrator account as the only owner. Shared ownership improves continuity, but it should not remove individual accountability.

Identify the real blast radius

Blueprints can include required resource access and inheritable permissions. These settings deserve a separate review because permissions granted to a blueprint principal may flow to agent identities created from that blueprint.

For each permission:

• Identify the target resource API.
• Classify the permission as delegated or application permission.
• Record whether it is read-only, write-capable, or administrative.
• Confirm that the permission is required by the agent's documented function.
• Remove unused permissions only after testing the affected agent.
• Require administrator consent for high-impact permissions.

Use a simple risk classification:

• Low: read-only access to a narrow, approved dataset.
• Medium: write access to a business system or broad directory read access.
• High: directory writes, credential management, mail sending, broad SharePoint access, or security administration.

High-risk blueprints should have a separate approval path and stronger monitoring.

Use an allowlist

Create an allowlist rather than relying on broad tenant defaults.

A practical operating model is:

• A small platform team owns production blueprints.
• Developers may request new blueprints but do not receive permanent production provisioning rights.
• Business sponsors approve the purpose and data scope.
• Security or identity administrators approve permissions and credentials.
• Every new agent identity receives an owner, sponsor, expiration or review date, and documented purpose.

For smaller tenants, one person may perform more than one role, but the approval steps should still be recorded separately.

Pilot before broad enforcement

Before enforcing a tighter policy across the tenant:

1. Select one non-production blueprint.
2. Remove unnecessary creator access.
3. Confirm that an approved owner can still create the required test identity.
4. Confirm that an unapproved user cannot create an identity through the blueprint.
5. Test the agent's normal authentication and API calls.
6. Review Entra audit events and Microsoft 365 agent activity insights.
7. Document the result and rollback procedure.

Do not test by creating identities in production. Use a test blueprint with non-sensitive permissions.

Make governance recurring

Recommended cadence:

• Weekly: review new blueprints and new agent identities.
• Monthly: review owners, sponsors, credentials, and high-risk permissions.
• Quarterly: remove unused blueprints and rotate credentials according to policy.
• After a team change: revalidate ownership and sponsorship immediately.
• After a Microsoft change notice: repeat the permission and access review.

Keep the inventory in a controlled location and record the date, reviewer, decision, and evidence for every change.

Record the evidence

• [ ] Tenant-level agent access settings recorded.
• [ ] Every agent blueprint inventoried.
• [ ] Every blueprint has a current owner.
• [ ] Every blueprint has a current sponsor.
• [ ] Required resource access reviewed.
• [ ] Inheritable permissions reviewed.
• [ ] Credentials and federated identity configuration reviewed.
• [ ] Production creator access reduced to an allowlist.
• [ ] Non-production restriction test completed.
• [ ] Entra and Microsoft 365 audit evidence captured.
• [ ] Next review date assigned.

Treat blueprints as provisioning authorities

Agent identity blueprints are not just configuration objects. They are provisioning authorities. The safest response to the permission change is to identify every blueprint, assign accountable owners and sponsors, reduce creator access to a deliberate allowlist, and verify that high-impact permissions cannot be inherited without review.

Microsoft documentation

• 365Forge Live Feed: https://365forge.net/feed
• Microsoft Learn: Create an agent identity blueprint: https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/create-blueprint
• Microsoft Learn: Agent identity blueprints in Microsoft Entra Agent ID: https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/agent-blueprint
• Microsoft Learn: Agents admin guide for Microsoft 365: https://learn.microsoft.com/microsoft-365/copilot/agent-essentials/m365-agents-admin-guide
• Microsoft Learn: Agent settings in Microsoft 365 admin center: https://learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-settings?view=o365-worldwide