Access Control for Agents: Conditional Access and Access Packages

The previous articles established that an agent has its own identity, is stamped from a blueprint, appears in a registry, and is bound by least privilege. This article is about the last mile: how those decisions are actually enforced, every time the agent tries to do something, using the same practical controls that already protect your people.

1 · Delegated access: acting on a person’s behalf

Many agents do not act with permissions entirely of their own; they act on behalf of a specific person, using that person’s own access. This is delegated access — the agent extends a human’s reach rather than holding a separate, standing grant. Think of an assistant who can send email as you, using your mailbox permissions, not a mailbox of their own.

This matters for access control because it means the protections already guarding that person’s sign-in can extend naturally to the agent acting for them. If the person is protected by strong sign-in rules, the agent working on their behalf should be checked by the same rules — which is exactly what the next two sections describe.

2 · Conditional Access for agents

Conditional Access is a policy engine: it checks the conditions surrounding a sign-in or request — where it is coming from, what device is involved, how risky the pattern looks — and can allow, challenge, or block it accordingly. It is one of the most widely used controls in Microsoft Entra for people, and it now extends to agents with delegated access, applying the same conditional checks to the agent’s actions as would apply to the person it represents.

The value is that access is not a single yes-or-no decision made once at setup. Every request is re-evaluated against current conditions, so an agent acting from an unexpected pattern can be challenged or stopped in the moment, not discovered afterward in a log.

3 · Identity Protection for agents

Identity Protection is real-time risk detection: it watches sign-in and behaviour patterns, flags ones that look abnormal, and can respond automatically — for example, by requiring additional verification or blocking the action outright. Extended to agents, it means an agent that starts behaving unlike itself, reaching for data it never touched before, acting at an unusual time, is caught by the same detection watching your people, rather than slipping past unnoticed.

Together, Conditional Access and Identity Protection form a live pair: one checks the conditions of each request against policy, the other watches for abnormal patterns across requests over time. An agent with delegated access is covered by both, the same as the human it acts for.

4 · Network traffic controls

Identity checks are not the only lens. Organisations can also monitor and block malicious or noncompliant network traffic for agents — whether the agent is operating on a user’s device or is a Copilot Studio agent. Network-level visibility catches a different class of problem: connections that look wrong at the traffic level, even if the identity presenting them appeared valid at the sign-in step.

Adding this layer means agent access is guarded from two angles at once: who is asking and what they claim to be (identity), and what the traffic itself looks like (network). A single layer can miss things the other catches, which is why both are applied together.

5 · Sponsor-driven lifecycle policies

Access that is granted once and never revisited is exactly how standing risk accumulates. Microsoft Entra addresses this with built-in lifecycle policies that automate sponsor-driven workflows, which keep the accountable human, the agent’s sponsor, in the loop automatically as the agent’s access is created, reviewed, and eventually retired.

The word “automate” is doing real work here. Instead of relying on someone remembering to review an agent’s access every quarter, the platform triggers that review on a schedule and routes it to the sponsor, so accountability does not depend on a person’s memory. This is the same discipline from earlier articles, access that does not persist longer than needed, now expressed as an automated workflow rather than a manual chore.

6 · Access packages: governed onboarding

When it is time to actually grant an agent access, assembling permissions one at a time, by hand, for every new agent is exactly the inconsistency problem blueprints were built to avoid at the identity layer. The access-control equivalent is the access package: a predefined bundle of permissions and policies that can be assigned to an agent in a single step.

Security teams define what a given kind of agent should be allowed to do once, as a package, and IT teams apply that package during onboarding. The result is that governance and compliance are enforced from the start of an agent’s life, not bolted on afterward. An agent onboarded through an access package begins its working life already matching an approved, reviewed shape, rather than accumulating whatever permissions seemed convenient at setup time.

7 · Glossary — every short-form term, spelled out

Delegated access

Access an agent uses on behalf of a specific person, drawing on that person’s own permissions rather than a separate grant.

Conditional Access

A policy engine that checks the conditions of a request and can allow, challenge, or block it before it proceeds.

Identity Protection

Real-time risk detection that watches for abnormal sign-in or behaviour patterns and can respond automatically.

Network traffic controls

Monitoring and blocking of malicious or noncompliant network connections associated with an agent.

Lifecycle policy

An automated rule that governs an identity’s access over time — creation, review, and retirement — without manual intervention.

Sponsor

The human accountable for an agent, kept in the loop automatically by lifecycle policies.

Access package

A predefined bundle of permissions and policies that can be assigned to an agent in a single step, ensuring consistent, governed onboarding.