ENow | AppGov Blog

Agents in Entra: Security Risks and Governance Best Practices

Written by ENow Software | Jan 16, 2026 7:07:17 PM

Agents are changing how people work. With Copilot Studio and other agent-authoring solutions, people in your organization can now build and extend their own agents to automate tasks, retrieve data, and connect business workflows. Admins and developers can use Azure AI Foundry, Security Copilot, and other Agent-authoring solutions to build and extend agents. It feels magical the first time you see it at work.

Here is the part many IT and security professionals do not realize:

Those Copilot Studio agents are tied to identities inside Microsoft Entra.

In many implementations, creating or extending an agent results in new Entra-governed identities that behave similarly to Entra enterprise applications (serviceprincipals) as part of Entra Agent ID:

  • Agent identity blueprints
  • Agent identity blueprint principals
  • Agent identities and sometimes even agent users

Agents are not just productivity helpers. They typically represent identities inside Entra, which means they come with permissions, access paths, and governance responsibilities.

If these identities are not discovered and managed, they may quietly expand the identity attack surface inside Entra.

The exact way agents are represented in Entra may evolve over time, as Entra Agent ID is currently still in preview, but the core reality remains the same: Agents introduce identities and permissions that must be governed.

Do Agents Create ServicePrincipals in Entra ?

When agents are created, installed, or extended, they are represented in Microsoft Entra using identity objects so they can authenticate and request access to resources. Microsoft is now introducing Entra Agent ID, a purpose-built identity platform designed specifically for AI agents. This model introduces new constructs such as agent identity blueprints, agent identity blueprint principals, agent identities, and agent users, which are distinct from application service principals, even though they leverage the same serviceprincipal infrastructure under the hood.

On top of that, Microsoft also offers the Entra Agent Registry, featuring agent instances, that offers an extensive repository of agent metadata and agent sponsors.

Today, depending on the platform, tenant state, developer maturity, and agent creation path:

  • Some previously created agents use traditional application service principals
  • Agents created using agent-aware agent-authoring solutions like Copilot Studio, Azure AI Foundry, and Security Copilot, use agent identity blueprints, agent identity blueprint principals, agent identities and (sometimes) agent users.
  • Both models may coexist in the same tenant

Over time, Microsoft is shifting toward Entra Agent ID as the native identity model for agents, especially to support scale, ephemerality, impersonation, and clearer auditability.

Here’s a Microsoft overview of key differences between agent principals and nonagentic principals.

The practical takeaway for IT, identity, and security teams

Agents result in non-human identities in Entra that request permissions and perform actions across Microsoft 365, Microsoft Azure, Microsoft Graph, and other apps, services, and systems your organization utilizes.

Whether those identities appear as:

  • Application service principals, or
  • Agent identity blueprints, agent identities and agent users,

they still introduce access, permissions, ownership, and lifecycle considerations that require governance.

The mechanism may change, but the responsibility does not: Agents create identity objects in Entra, and those identities must be reviewed, scoped, monitored, and governed just like any other workload identity. As such, Entra Agent ID is an evolution of the application model already present in Entra.

The New Principal Sprawl

Let's look at three common scenarios.

Let's start with business users. If you have ever watched a business user discover an agent-authoring solution like Copilot Studio, you know exactly what happens: Ideas start flying, prototypes appear quickly, and suddenly agents are connected to live data.

It is exciting. It also bypasses the traditional software development life cycle (SDLC) and change control guardrails that IT relies on.

Many business users (and citizen developers):

  • are not trained in least privilege or DevSecOps principles.
  • focus on getting the tool working, not designing permissions.
  • do not document ownership or lifecycle plans.
  • leave behind agent blueprints when they move on

Another common story revolves around team workshops. A team builds an agent during a workshop featuring Copilot Studio, Azure AI Foundry, Security Copilot, or a third-party agent-authoring solution. People change jobs. Now nobody can tell you who owns it, yet the Agent blueprint and its inheritable API-permissions still exist in Entra, and no one knows who's responsible.

Here is another real example: An engineer creates a proof-of-concept agent during an internal project. The pilot is abandoned. The agent resources persist for years. No one notices until an audit.

This is how yesterday’s app sprawl becomes today’s agent sprawl.

How to find agents in Entra

The first time many admins go looking for agents in Microsoft Entra, the surprise is not that agents exist, but how many non-human identities are present, and how differently they surface depending on the identity model – the application or the agent model - used.

With Entra Agent ID, Microsoft now provides a dedicated control plane for agent discovery.

Admins can:

  1. Open the Microsoft Entra admin center
  2. Navigate to Entra ID > Agent ID > All agent identities
  3. Review the full list of agents in the tenant
  4. Select any agent identity to review:
    1. Owners and sponsors
    2. Audit logs and sign-in logs
    3. Current status, including the ability to disable the agent
  5. Review information in the Agent Repository
  6. Manage Agent ID settings
  • This view is now the most reliable way to understand which agents exist and how they authenticate. Filter for Microsoft applications or search for terms like “Copilot” or “agent”
  • Review newly created service principals
  • Inspect Microsoft Graph permissions, consent history, and role assignments

These service principals behave like traditional application identities, not agent identities, but they still execute agent actions and carry standing access that must be governed.

Why is this distinction important?

Most tenants today contain a mix of agent identity objects and application service principals representing agents.

The Agent ID view makes this distinction explicit for the first time. Once admins can see which agents are using purpose-built Agent ID identities versus legacy service principals, governance conversations shift from “Do we have agents?” to “Which identity model are they using, what access do they have, and who owns them?”

That awareness is often the turning point.

Security Risks Introduced by Agents

When agents are created without deliberate identity and lifecycle controls, it introduces familiar identity and access risks, but at far greater speed and scale.

Common security risks introduced by agents include:

  • Agent principals created outside formal IT intake processes
    Business users can create and embrace agent functionality quickly, resulting in new agent principals appearing in Entra without review.
  • Microsoft Graph permissions granted through consent
    Users approve delegated or application permissions to continue building or testing an agent, often without understanding the tenant-wide impact of those permissions.
  • Abandoned agents and Agent ID blueprints remain
    Pilot agents may be retired, but the Agent ID blueprints may never get cleaned up.
  • Unclear ownership and accountability for agent resources
    Agent principals often lack assigned owners or still-employed sponsors, making it difficult to reassess business justification when people change roles or leave the organization.
  • Persistent service principals or agent identities that no one remembers creating
    Over time, environments accumulate agent-related identities that blend into the broader identity inventory, increasing review fatigue and audit blind spots.

Entra Agent ID Governance Best Practices for IT and Security

You do not need to ban agents from your organization to stay secure – although you can in the Settings view in Entra Agent ID. The goal is not to block everything. The goal is to make sure what gets created is visible, owned, and right sized for risk.

Recommended Entra Agent ID governance controls include:

  • App Consent Policies to define who can approve new Copilot-related apps
  • Conditional Access to manage sign-in and session requirements for the identities used by Copilot agents, based on risk, location, device posture, or user context
  • Privileged Identity Management to restrict who can grant tenant-wide consent
  • lifecycle governance so agents are owned, justified, reviewed, and retired

Governance is simply how you prevent yesterday’s tests from becoming tomorrow’s incident.

How Microsoft’s Agent 365 Control Plane Helps Manage AI Agents

As agents proliferate, Microsoft has introduced new controls to help manage them. At Ignite, Microsoft announced Agent 365, a control plane focused on AI agent identities. Underneath Agent 365, Entra Agent ID formalizes agents as a new identity type in Entra.

Agent 365 helps organizations with:

  • centralized inventory and discovery of agents
  • visibility into agent permissions and access
  • telemetry and behavioral monitoring
  • lifecycle control and deprovisioning

Agent 365 does not replace internal governance policies. Instead, it strengthens the native foundation as agent usage grows.

Availability and specific capabilities of Agent 365 and Agent ID will continue to evolve as Microsoft rolls them out across tenants, so organizations should expect the control model to mature over time. This functionality is currently in Public Preview.

How ENow AppGov Score Strengthens App Governance in Entra

Microsoft provides some controls. Security teams still need clarity.

ENow AppGov Score helps organizations:

  • discover Copilot Studio agents and Entra enterprise applications
  • identify risky or excessive permissions
  • find orphaned service principals without owners
  • benchmark their governance posture through a free assessment report
  • prioritize remediation based on actual risk

Instead of chasing applications one at a time, AppGov Score gives you the full picture of app governance in Entra so you can move from reactive cleanup to proactive decision-making.

Bottom Line for Security and Identity Teams

Agent-authoring solutions like Copilot Studio, Azure AI Foundry and Security Copilot are not just features. Agents are identities that connect to your real users and your real data. They appear in Entra, and they carry permission, ownership, and lifecycle risks.

You do not have to solve everything at once. That may even be overwhelming.

Start by looking. See what already exists. Notice agent and application sprawl. Once you have visibility, governance decisions become far easier and far less political.

The path is straightforward:

  • discover agents
  • understand what they access
  • manage ownership and sponsorship
  • manage lifecycle
  • use Agent 365 and AppGov Score to scale oversight

Organizations that start this work now reap the benefits of AI while keeping identity and access security strong across Entra.

Questions Security & Identity teams usually ask about Agent Security

“We already govern apps in Entra. What’s different here?”

You’re already ahead if you have an app governance program in place. What is different is how agents are created and how they work under the hood.

Agents are often created using end-user tools like Copilot Studio. That means they can be built by business users outside traditional IT intake. Even mature Entra governance programs may not yet account for:

  • agents being created rapidly by non-developers
  • Entra Agent ID objects emerging as new identity types
  • agents chaining actions across multiple systems

So, the technology is familiar, but the speed, creators, and scale are vastly different.

 

“Do agents expand the attack surface, or is this just hype?”

Yes, they can expand the identity attack surface if they are not governed.

The most common risk patterns we see include:

  • overly broad Graph permissions approved by non-technical users
  • agents that are abandoned but linger
  • unclear ownership or justification
  • default trust because “Copilot” sounds safe

It is not hype, it is the same pattern we have already seen with SaaS sprawl, only now it happens faster and more automatically.

“Isn’t Microsoft solving this already with Agent 365?”

Microsoft is taking important steps. Agent 365 and Entra Agent ID add:

  • a control plane for agents
  • a defined identity type specifically designed for agents
  • stronger visibility and policy hooks

What they do not replace is your internal governance responsibilities. Organizations still need to:

  • define ownership
  • review permissions
  • manage lifecycle
  • decide acceptable risk levels

Agent 365 helps, but it does not automatically remove abandoned agents or design your governance processes for you. In practice, most enterprises use native controls plus independent oversight and reporting.

 

“As Copilot Studio, Azure AI Foundry, and Security Copilot are Microsoft products, why do we need to worry about them?”

Because what matters is permissions and data, not the brand name on the product.

“Microsoft-built” does not automatically mean:

  • least-privilege for your tenant
  • alignment with your internal policies
  • appropriate risk level for your business
  • automatic inventory and lifecycle management

Security teams mainly care about:

  • what data an agent can reach
  • what actions it can take
  • who owns it
  • who is accountable when something goes wrong

That is why agent-authoring solutions still need governance, even though the solution is a Microsoft product.

“Can’t we just block agent creation entirely?”

Yes, you can, but most organizations find that hard blocks create workarounds.

What usually happens if you block:

  • business units move to shadow environments
  • users recreate agents unofficially
  • value from AI is limited

The approach that works best is governed enablement, not prohibition. That means:

  • discover what exists
  • assess risk
  • monitor activity
  • control high-risk agents
  • restrict privilege elevation

You get the benefit without introducing unnecessary exposure.

“Show me evidence that agents exist in our tenant before I care.”

That is the most common and reasonable objection we hear. Afterall, we're all entering and navigating this new frontier together! 

We've found that the evidence usually shows up as:

  • Entra Agent ID resources you did not know were there
  • newly created Agent ID blueprints and blueprint principals
  • permissions no one remembers consenting to
  • agents created by business users rather than IT
  • identities that show “owner unknown”

What's Next?

Discovery is often the moment when the conversation shifts. Tools like the Entra admin center Agent capabilities, and ENow App Governance Accelerator make it easy to surface what already exists in your environment and separate assumptions from reality so you can have honest conversations about how your tenant and data is accessed and secured.

Stay tuned for additional blogs as Microsoft continues to evolve how we manage non-human identities and agents!