Conditional Access for AI Agents: What Mid-Market Teams Without Microsoft E7 Should Do

Microsoft is developing new controls to govern what AI agents can access and do inside enterprise environments. On October 19, 2026, Microsoft announced Dynamic Permissions, Dynamic Agent Risk and Dynamic Conditional Access for agents. These capabilities are designed to give agents task-specific permissions and adjust their access as risk changes. On October 29, Microsoft also published documentation for Conditional Access policy plans, a preview feature that helps administrators organise shared conditions and rules, including controls for agent activity.

These developments matter, but organisations should understand the licensing requirements before planning around them. Microsoft 365 E7 includes the relevant Agent 365 and Entra capabilities, but E7 is not the only licensing route. Mid-market teams without E7 can use Microsoft Agent 365 with qualifying Entra or Microsoft 365 licences. Teams without those options still need to govern agents, OAuth grants and application access through the controls available in their environments.

What Microsoft Announced

Three capabilities from Microsoft's October 19 announcement are particularly relevant.

Dynamic Permissions: Agents begin with no authority and receive only the permissions required for an approved task. Access can be scoped to the task, time-limited and reduced or removed as the task changes or finishes. Higher-impact actions can require verified human approval.

Dynamic Agent Risk: Microsoft combines signals from identity, data, endpoints, cloud, network, runtime and agent activity to continuously assess an agent's risk. The aim is to identify when an agent's behaviour or access no longer matches its intended task.

Dynamic Conditional Access: This extends Conditional Access for agents so that changing risk can trigger graduated responses. These can include preserving read access while blocking writes, narrowing accessible resources, requiring human approval or isolating the agent.

These were announced capabilities; organisations should check Microsoft's current product documentation and tenant availability before assuming they can deploy them.

Source: Microsoft Security – Agents are your newest insiders

What the Licensing Actually Requires

Microsoft Entra Conditional Access for agents is not exclusive to Microsoft 365 E7. Microsoft's current documentation lists two licensing routes:

• Microsoft 365 E7, which includes Agent 365 and Microsoft Entra Suite.

• Microsoft Agent 365 paired with at least Microsoft Entra ID P1 or Microsoft 365 E3.

There is an additional requirement for risk-based agent policies: Microsoft lists Agent 365 paired with Entra ID P2 or Microsoft 365 E5.

This distinction matters. A company without E7 may still qualify for agent-specific Conditional Access through the Agent 365 add-on and the required base licence. Organisations should verify their exact feature entitlements before budgeting or designing policies.

Source: Microsoft Learn – Conditional Access for agents

The Gap: Apps, OAuth Grants and Agents Outside Entra

Conditional Access can only enforce controls along the authentication and resource paths it protects. Microsoft's documentation makes an important boundary clear: Conditional Access protects resources secured by Microsoft Entra ID. If an agent accesses a service directly using an API key, it bypasses Entra's token issuance process, so those Conditional Access policies do not apply.

That leaves teams needing visibility into more than employee sign-ins. Agents may use delegated OAuth permissions, application identities, service accounts or API keys. Some operate through third-party SaaS platforms, while others run as scripts or scheduled automations.

A useful inventory should identify the application or agent, its owner, the identity it uses, the permissions granted, the resources it can reach and the method used to authenticate.

Source: Microsoft Learn – Conditional Access for agents: boundaries and limitations

A Five-Step Checklist for Mid-Market Teams

1. Inventory applications and OAuth grants. Review connected applications in Microsoft 365, Google Workspace and other identity platforms. Include user- and admin-approved OAuth grants. Record the application, owner, permissions, connected users and last-used information where available.

2. Find agents and non-human identities. Look for service accounts, API keys, scheduled automations, MCP connections and AI assistants with access to company systems. Use expense records, identity logs and browser activity as discovery sources. Assign an accountable owner to every identified agent or integration.

3. Apply least privilege. Compare each agent's permissions with its actual task. Remove unnecessary write access, narrow broad integration permissions and separate shared accounts where possible. Use project, resource and time restrictions when the relevant platform supports them.

4. Enforce SSO and sign-in conditions. Route supported applications through SSO. Apply conditions such as approved IP addresses, devices and regions where your identity and application setup supports them. Test policies in report-only or equivalent modes before enforcement, and maintain emergency access procedures.

5. Monitor and review access. Review application inventories and permissions regularly. Investigate new OAuth grants, unexpected sign-ins and access outside an agent's approved scope. Revoke unnecessary access when employees leave, agents are retired or integrations are no longer required.

Where OptyStack Fits

OptyStack helps organisations improve visibility into SaaS and AI applications. Its discovery capabilities use spend, SSO and browser signals to identify applications, map usage to users and surface potential Shadow IT and Shadow AI activity.

For human-user access to connected third-party applications, OptyStack acts as an identity broker. It imports users from Google Workspace, Microsoft or Okta and checks sign-ins against configured IP address, device and region conditions. If a condition is not met, access to the connected app is denied.

These capabilities support application discovery and human-user sign-in control. They should not be confused with Microsoft's agent-specific identity controls. OptyStack does not provide Dynamic Permissions or Dynamic Agent Risk, issue identities to AI agents, or replace dedicated API-key and secrets-management controls.

Learn more about OptyStack identity management.

Start With Visibility

Conditional access for AI agents begins with knowing which applications, identities and integrations exist. Microsoft is building more specialised controls, but licensing, resource coverage and authentication methods determine where those controls can actually apply.

Mid-market teams should start by inventorying applications and agents, identifying how they authenticate, reducing unnecessary permissions and enforcing the sign-in controls available to them. That creates a stronger foundation for adopting agent-specific controls as their licensing and platforms allow.

Create an OptyStack account to explore SaaS and AI application visibility.