Start with agent inventory and classification

This article is part of a multi-part series on Microsoft Entra Agent ID governance. For the full sequence and recommended reading order, start from the Governing AI agents with Microsoft Entra Agent ID and Agent 365

Before creating Conditional Access policies, access packages, lifecycle workflows, or custom security attribute rules, start with the simplest question: what agents exist in the environment?

That sounds basic, but it is the most important step in an Agent ID governance journey. Agents can come from different platforms, use different identity models, and have different levels of visibility in Microsoft 365 and Microsoft Entra. If the inventory is incomplete or poorly classified, every later governance decision becomes risky.

The purpose of inventory is not just to create a list. The purpose is to understand which agents are ready for governance, which agents need cleanup, which agents are unknown, and which agents should be excluded from business-agent review.

Licensing note: Microsoft Entra ID Governance for agent identities requires either Microsoft 365 E7, or Microsoft Agent 365 paired with at least Microsoft Entra ID P1 or Microsoft 365 E3. For licensing, refer to the Microsoft Agent 365 plans and pricing.

Why inventory comes first

AI agents may be created or discovered from different places:

• Microsoft Copilot Studio
• Microsoft 365 Copilot Agent Builder
• Azure AI Foundry
• Amazon Bedrock
• Google Vertex AI
• Other third-party platforms
• Custom or pro-code agent platforms
• Shadow AI or endpoint-discovered tools
• System-created or built-in platform objects

These agents should not all be treated the same way.

Some agents may have a Microsoft Entra Agent ID. Some may still use an app registration or service principal model. Some may only be visible through registry sync. Some may be discovered as shadow AI activity. Some may be system-generated objects that should not be handled like customer-created business agents.

That is why the first phase should focus on inventory and classification, not enforcement.

What the inventory should answer

A useful agent inventory should answer the following questions.

Question	Why it matters
What agents exist?	Establishes full visibility of the agent estate.
Which platform created or surfaced the agent?	Determines the likely governance path.
Does the agent have Microsoft Entra Agent ID?	Determines whether Agent ID-specific controls can apply.
Is the agent user-created, system-created, or third-party discovered?	Prevents incorrect governance of built-in or system objects.
Does the agent have an owner and sponsor?	Identifies accountability gaps.
What access pattern does the agent use?	Determines the correct Conditional Access and access governance model.
Is the agent approved, unknown, legacy, unmanaged, or orphaned?	Determines the next corrective action.

Screenshot: Agent inventory table showing source platform, identity type, owner, sponsor, access pattern, and governance state

Minimum inventory fields

The inventory should capture enough information to support governance decisions, not just reporting.

Field	Purpose
Agent name	Basic identification.
Source platform	Identifies where the agent came from.
Environment, tenant, or region	Helps with platform ownership and operational scoping.
Identity state	Captures whether the agent uses Agent ID, app registration, service principal, agent user identity, registry-only visibility, or unknown identity.
Microsoft Entra Agent ID present	Identifies whether Agent ID controls are relevant.
Owner	Technical or operational administrator.
Sponsor	Business accountable person.
Business purpose	Explains why the agent exists.
User-created or system-created	Helps avoid applying business governance to built-in objects.
Access pattern	Classifies whether the agent acts on behalf of a user, acts autonomously, or uses its own user-like identity.
Data sensitivity	Helps prioritise protection and review.
Business criticality	Helps prioritise governance effort.
Approval status	Tracks whether the agent is new, under review, approved, rejected, or revoked.
Governance state	Tracks whether the agent is active, ReviewRequired, orphaned, unmanaged, retired, or policy-ready.
Recommended action	Captures the next step for that agent.

Classification model

Once the inventory is collected, classify every agent into a practical governance bucket. This avoids treating every discovered object as the same type of agent.

Classification bucket	Meaning	Recommended action
Entra Agent ID-backed agent	Agent has a Microsoft Entra Agent ID.	Move to governance design if owner, sponsor, purpose, and access pattern are known.
Agent ID-backed but missing accountability	Identity exists, but owner or sponsor is missing.	Fix accountability before enforcement.
Legacy app registration or service principal-backed agent	Agent uses older app registration or service principal model.	Track separately and validate governance path.
Microsoft 365 Agent Builder agent	Agent created through Microsoft 365 Copilot Agent Builder.	Govern through the appropriate Agent 365 or Microsoft 365 controls. Do not assume Agent ID behaviour without validation.
Third-party registered or synced agent	Agent discovered through registry sync or external platform integration.	Reconcile with the source platform and validate supported governance actions.
Shadow AI or local agent	Agent or AI tool detected through endpoint or security signals.	Review through endpoint and security governance processes.
System-created or built-in object	Platform-generated or connector-like object.	Exclude from business-agent governance review unless risk-relevant.
Unknown or unclassified agent	Source, owner, sponsor, purpose, or identity model unclear.	Mark as ReviewRequired.
Orphaned agent	No valid owner, no sponsor, and unclear business purpose.	Run claim-or-retire process.
Policy-ready agent	Fully classified, accountable, and approved.	Include in Conditional Access, access package, lifecycle workflow, and monitoring design.

Access pattern classification

Identity state alone is not enough. The access pattern also matters.

Access pattern	Meaning	Governance implication
On-behalf-of user	Agent acts using the signed-in user’s delegated context.	Existing user Conditional Access and user permissions are highly relevant.
Autonomous or app-only	Agent operates independently using its own identity or application permission.	Agent identity controls, app permissions, access packages, and agent-specific Conditional Access become relevant.
Agent user identity	Agent behaves like a user-like identity with its own mailbox, Teams presence, or directory identity.	Stronger lifecycle, licensing, content access, and collaboration governance may be needed.
Unknown	Access behaviour is not confirmed.	Do not enforce final policies until clarified.

Corrective actions after inventory

Inventory should not remain a static report. It should drive cleanup.

Inventory finding	Recommended action
Agent has no owner and no sponsor	Treat as orphaned or ReviewRequired. Ask platform or business team to claim ownership, otherwise move to retire or disable review.
Agent has sponsor but no owner	Confirm or nominate the correct technical owner.
Agent has owner but no sponsor	Assign a business sponsor before lifecycle or access governance.
Source platform unknown	Keep in ReviewRequired state until source is validated.
Identity model unknown	Classify as Agent ID, app registration, service principal, agent user, registry-only, shadow AI, or unknown.
Access pattern unknown	Do not move into final Conditional Access design until access pattern is confirmed.
System or built-in object	Exclude from business-agent governance unless risk-relevant.
Agent fully classified and accountable	Move to policy design.

Gatekeeping for new agents

The first inventory helps clean the current state. The next challenge is preventing the same gaps from coming back.

For newly created agents, define a minimum metadata gate before the agent is considered production-ready. At minimum, the agent should have:

• Owner
• Sponsor
• Business purpose
• Source platform
• Environment
• Access pattern
• Data sensitivity
• Business criticality
• Approval status
• Governance state

Agents that do not meet the baseline should remain in ReviewRequired state. They should not be treated as approved just because they exist.

This helps the organisation move from manual housekeeping to a repeatable operating model.

Recommended outcome of this phase

By the end of the inventory and classification phase, the organisation should be able to answer:

• How many agents exist?
• Where did they come from?
• Which agents have Microsoft Entra Agent ID?
• Which agents are legacy, third-party, shadow, or unknown?
• Which agents are user-created versus system-created?
• Which agents are missing owner or sponsor?
• Which agents are orphaned?
• Which agents are ready for policy design?
• Which agents need further investigation before enforcement?

Wrap-up

Agent governance should not start with policy creation. It should start with visibility.

Inventory gives the organisation a clear view of the estate. Classification turns that view into action. Once agents are classified, accountable, and approved, the organisation can safely move into the next stage: using custom security attributes as the governance metadata layer.