An agent’s permission model is only trustworthy if it is enforced when the agent acts, not merely recorded when the agent is created. Microsoft Entra treats agent access as a live decision: who the agent represents, what conditions surround the request, whether the behavior looks risky, whether the traffic is acceptable, who remains accountable, and whether the access was granted through a governed path.

Access control is a runtime discipline

Earlier governance work gives an agent an identity, assigns it a blueprint, places it in a registry, and defines what it should be allowed to do. Those are necessary steps, but they are not enough. The real test comes later, when the agent tries to read data, invoke a tool, send a message, or call a service.

At that moment, the organization needs a control plane that can say yes, no, or not yet. It must evaluate the request against current policy, not just against a static permission granted weeks ago. That is the role Microsoft Entra plays for agents: it brings sign-in policy, risk detection, network controls, lifecycle governance, and packaged access together so that agent activity is checked in practice.

This is especially important because agents can act quickly and repeatedly. A mistaken permission on a human account may be used occasionally. A mistaken permission on an agent may be exercised at machine speed. The answer is not to stop agent adoption, but to make the safe path the default path.

📌
The control point. The important question is not only what an agent is allowed to do, but what is checked each time it tries to do it.

Delegated access ties an agent to a person

Many agents do not hold all access independently. They act on behalf of a specific person and use that person’s permissions. This is delegated access: the agent extends a human user’s reach rather than operating with a separate standing grant of its own.

A simple example is an assistant that drafts or sends email using a user’s mailbox permissions. The agent is not being given a mailbox as its own resource. It is acting in the context of the person who authorized the work.

That distinction matters because delegated access lets existing human protections follow the work. If the person’s access is subject to strong sign-in rules, risk checks, and policy conditions, the agent acting for that person should be measured against those same controls. The agent is not a loophole around the human access model; it is another way that model is exercised.

A delegated agent acts on a person's behalf using that person's permissions. Delegated Access authorizes acts via user Usergrants reach Agenton behalf of Resourcemailbox, data
A delegated agent acts on a person's behalf using that person's permissions.

Conditional Access checks the circumstances

Conditional Access is Microsoft Entra’s policy engine for evaluating the conditions around a sign-in or request. It can consider signals such as where a request comes from, what device is involved, whether the pattern appears risky, and what policy applies to the user or workload. Based on those conditions, it can allow the request, require an additional step, or block it.

For agents with delegated access, Conditional Access extends the same style of control to the agent’s actions. The agent does not simply inherit a blanket yes because it was approved during setup. Each action can be evaluated against the current situation.

This changes access control from a one-time gate into a continuous decision. A request that looked acceptable yesterday may be blocked today if it comes from an unexpected place, uses a noncompliant device context, or matches a condition the organization has decided is too risky.

Conditional Access weighs each request and allows, challenges, or blocks it. Each Request Checked Evaluate conditions low risk elevated high risk Allowproceed Require stepverify Blockdenied
Conditional Access weighs each request and allows, challenges, or blocks it.

Identity Protection and network controls add risk awareness

Conditional Access evaluates policy conditions at the time of a request. Identity Protection adds another lens: real-time risk detection. It watches for abnormal sign-in and behavior patterns, then can trigger automatic responses such as requiring additional verification or blocking activity.

For agents, this matters because not every bad request looks bad in isolation. An agent may authenticate successfully and still behave in a way that is unusual for its role: reaching unfamiliar data, acting at odd times, or shifting patterns suddenly. Identity Protection helps identify that drift.

Network traffic controls add a different view again. Organizations can monitor and block malicious or noncompliant network traffic associated with agents, including agents running on a user’s device and Copilot Studio agents. Identity controls ask who is acting and under what policy. Network controls examine the traffic itself. Both views are useful because either one can catch what the other misses.

Sponsors keep access accountable over time

Access that is granted once and never revisited becomes standing risk. This is true for people, applications, service accounts, and agents. The difference with agents is that their usefulness can change quickly: a pilot becomes production, a project ends, a data source changes, or a tool is no longer needed.

Microsoft Entra addresses this with lifecycle policies that support sponsor-driven workflows. A sponsor is the accountable human for the agent. The point is not symbolic ownership; it is operational accountability. The sponsor is kept in the loop as access is created, reviewed, and retired.

Automation is what makes this durable. If a review depends on a person remembering to run it, it will eventually be missed. If the platform triggers the review and routes it to the right sponsor, the organization has a repeatable way to keep agent access time-bound.

⚠️
Standing access grows quietly. The riskiest agent permission is often the one nobody removed after the business need disappeared.

Access packages make governed onboarding repeatable

Granting permissions one by one for every new agent does not scale. It also creates inconsistency. Two agents built for the same purpose may end up with different access simply because different people configured them on different days.

An access package solves that problem by bundling approved permissions and policies into a predefined offering that can be assigned in one step. Security and governance teams define the shape once. Information technology teams and platform teams apply it during onboarding.

The practical benefit is that the agent starts from an approved baseline. Governance is not added later after the agent is already active. The package can include the permissions the agent needs, the policies that govern that access, and the workflow expectations around approval or review.

Access packages replace ad hoc grants with a repeatable approved baseline. Package the Access One by one Access package Configured ad hocper person Drifts apartinconsistent Added laterafter active Defined onceby governance Approved baselineconsistent Applied in one stepat onboarding
Access packages replace ad hoc grants with a repeatable approved baseline.

Decisions leaders and practitioners must make

The hard part is not knowing that agents need controls. The hard part is choosing where decisions belong and making those choices repeatable. Access control for agents crosses security architecture, identity operations, data governance, application ownership, and business accountability.

A useful design review asks a small set of practical questions. Does the agent act with delegated access or with its own permissions? Which Conditional Access policies should apply? What risk patterns should trigger intervention? Who sponsors the agent? Which access package should be used? How often should access be reviewed? What network traffic should be blocked or investigated?

These are not abstract governance questions. They decide whether a new agent can be onboarded safely in hours instead of debated for weeks, and whether security teams can prove later that the agent was controlled throughout its life.

  • Classify the agent’s access model before granting permissions.
  • Map delegated agents to the same protections that guard the people they represent.
  • Use access packages for common agent patterns instead of hand-built permission sets.
  • Assign a sponsor who can approve, review, and retire access.
  • Review identity signals and network signals together, not as separate silos.

How the controls work together

No single control carries the whole system. Conditional Access checks the circumstances of the request. Identity Protection looks for abnormal risk. Network controls inspect the traffic path. Lifecycle policies keep a human sponsor accountable. Access packages make the approved starting point easy to apply.

Together, these controls turn policy intent into operational enforcement. The organization decides what kind of agent is acceptable, packages that decision for onboarding, checks each action at runtime, watches for risk, and revisits the access over time.

That is the practical goal of agent access control: not to create a maze of approvals, but to make sure agents can work only inside a boundary that remains visible, current, and enforceable.

Key takeaways

  • Agent access must be enforced at the moment of action, not only approved at creation time.
  • Delegated access lets an agent act on behalf of a person, using that person’s permissions and protections.
  • Conditional Access evaluates the circumstances of each request and can allow, challenge, or block it.
  • Identity Protection and network traffic controls add risk detection beyond static permission checks.
  • Sponsor-driven lifecycle policies keep agent access accountable and time-bound.
  • Access packages make governed onboarding repeatable by bundling approved permissions and policies.
Layered Entra controls combine to keep each agent inside an enforceable boundary. Controls Together Access controlone boundary Conditional Accesschecks conditions Identity Protectionspots risk Network controlsinspects traffic Lifecyclekeeps current
Layered Entra controls combine to keep each agent inside an enforceable boundary.

Glossary

Access package
A predefined bundle of permissions and policies that can be assigned to an agent in a governed, repeatable way.
Conditional Access
A Microsoft Entra policy engine that evaluates request conditions and can allow, challenge, or block access.
Copilot Studio
A Microsoft platform for creating and managing agents and copilots that can participate in governed access and traffic controls.
Delegated access
An access model in which an agent acts on behalf of a specific person and uses that person’s permissions.
Identity Protection
A Microsoft Entra capability that detects risky sign-in and behavior patterns in real time and can trigger automatic responses.
Lifecycle policy
An automated governance rule that helps manage access through creation, review, and retirement.
Network traffic controls
Controls that monitor and block malicious or noncompliant network connections associated with agent activity.
Sponsor
The accountable human responsible for approving, reviewing, and retiring an agent’s access.