Entra agent ID conditional access is the gate in front of a SaaS tool, not a paragraph in an automation pitch. The agent has an identity in the directory. Before it calls a tool, Microsoft Entra ID has to issue a token to that identity for that tool, and a policy aimed at the agent has to allow it. A user policy that demands a second factor does not bind an app-only agent token. An API key stored next to the prompt skips the gate entirely. Rutagon builds the check that refuses the call until the token subject is the agent identity the policy was written for.
This is a security build for teams that already created agent identities and then let them call mail, files, and internal APIs with whatever credential was fastest. The identity write-up lives in Microsoft Entra agent ID. The work here is the conditional access decision on those identities, evaluated before the tool runs. We are not selling a general workflow product. We are stopping an agent from using a tool the directory did not authorize for that subject.
Which token the policy actually sees
Microsoft documents three access patterns, and they do not share a policy. In the on-behalf-of pattern a person is signed in, and the token subject is that person. Conditional access evaluates the user's policies. Selecting the agent identity as the subject does not cover that call. In the app-only pattern there is no signed-in person. The agent requests a token with its own identity, often through credentials managed on an agent identity blueprint, and the policy has to target that agent identity or the blueprint. In the agent-user pattern the token subject is the agent's own user account, and a policy aimed at the agent identity does not apply to it.
Those splits are the whole design. One "all users must satisfy multifactor" policy feels like coverage and misses the app-only call. Microsoft's Conditional Access for agents page is explicit: a policy that targets an agent identity does not apply to the agent's user account, and policies scoped through the users assignment do not apply to agent user accounts. You write a separate policy per token subject the agent actually uses. Rutagon inventories which pattern each tool uses before anyone argues about conditions.
The documented license path for this control is Microsoft 365 E7, which includes Agent 365 and the Entra suite, or an Agent 365 license paired with at least Entra ID P1 or Microsoft 365 E3. If that license is not on the tenant, the policy you draw in a workshop will not evaluate. We check the tenant before we promise a block.
A blueprint is the useful scope once you have more than a handful of agents. A policy on the blueprint applies to agent identities created from it, including identities created later. That is how a new agent inherits the SaaS boundary without someone remembering to edit a policy the night it ships. Custom security attributes do the same job when agents from several blueprints should share a rule, such as blocking a non-production agent from a production application.
Entra agent ID conditional access before the tool runs
The gate sits where the agent is about to call the SaaS application. The application has to be registered in the directory, because conditional access evaluates a subject and an audience at token issuance. If the tool is addressed by an API key, the call never enters that pipeline. Microsoft states the boundary directly: conditional access protects resources secured by the directory, and an API key bypasses token issuance. Our gateway treats that bypass as a deny. The agent does not get a quieter path around the policy.
For an autonomous agent using its own identity, the documented control is not an interactive prompt. There is no person to complete a challenge. The autonomous guidance says the available action is to block. The condition the agent-identity policy can use is agent risk. We deploy a block for high-risk agent identities, and we test it in report-only until the sign-in logs show the agent identities you expect and not the human users you do not. Turning enforcement on without that pass locks a production agent or, worse, teaches the team to stuff an API key into the tool so the policy "stops breaking things."
On-behalf-of calls are a different policy. The person is the subject, so the user's controls apply at the token exchange for the downstream audience. That exchange is where you stop an agent from reading mail the person may access but the agent should not reach on this workflow. We do not satisfy that requirement by scoping the agent identity. The sign-in log has to show the user as the subject and the SaaS app as the audience.
subject: agent identity for app-only calls, user for on-behalf-of calls
audience: the SaaS app registered in the directory
agent_identity_policy: block when agent risk is high
user_mfa_policy: does not bind the app-only token
api_key_call: denied at the gateway, because conditional access never sees it
The snippet is the decision we expect on every tool call. It is not a secret and it is not a full policy export. The export lives in the directory. The gateway log stores the application id, the subject type, and whether the call was refused before a request left the network. AI agent least privilege is the permission scope on the tools themselves. Conditional access is the decision that the token may be issued at all.
What breaks if you skip the subject split
Teams paste one policy, target "all users," and ship the agent with a client secret that never presents a user. The SaaS tool accepts the secret. Conditional access has nothing to evaluate. The audit log on the SaaS side shows a generic integration user. That is the failure mode we see when the demo worked on a developer's interactive login and the production job runs headless.
A second failure is targeting the agent identity and then letting the same agent act through an agent user account. The mailbox, the calendar, and the group memberships hang off the user account. The identity policy never fires. Microsoft documents that split so it is not a surprise in a design review. We create the agent-user policy on its own assignment, under agents, not under users. Group-based include of an agent's user account is called out as unsupported. If your operating model depends on a group, we say so before the policy is the control you cite.
Device conditions are another false comfort. An app-only agent identity does not carry a device. Endpoint and network conditions show up for agents that run as user accounts on managed endpoints, and the documented way to scope that is the agent execution environment condition so you do not demand a compliant device from a headless identity. We only attach those conditions to the pattern that can satisfy them.
Security defaults being enabled are a boundary too. Conditional access policies do not apply while security defaults are on. We do not discover that in production. The tenant either uses conditional access for these agents or it does not. There is no mixed story in the record.
Blueprint token calls that only create an agent identity are outside the tool policy on purpose. Microsoft limits blueprints so they are not themselves the actor that reads customer data. The agent identity does the work. We do not write a control that pretends the blueprint's setup call is the SaaS call.
What Rutagon ships
The deliverable is a map of tool calls to token subjects, a policy per subject, a gateway deny for any credential that is not a token, and a log line a reviewer can sample. Security automation is the place that build sits. We do not replace the directory, and we do not claim the tenant's compliance program. The engineering is the refusal path: no token for that audience, no tool call.
Report-only is part of the build, not a slide. We read the sign-in events, confirm app-only agents hit the agent policy, confirm on-behalf-of exchanges hit the user policy, and confirm API-key attempts die at the gateway with no SaaS response. Then enforcement turns on. A policy that has never been seen in a log is a rumor.
Rutagon's own automation uses short-lived identity for cloud calls and does not park long-lived keys in a prompt. The same habit applies here. If the only way the agent can reach the SaaS tool is a secret in a config file, the conditional access policy is decorative. We remove that secret as part of turning the gate on, or the record says the tool is still uncovered.
Frequently Asked Questions
Why doesn't a user multifactor policy cover an agent?
App-only access issues the token to the agent identity, not to a person. A policy assigned to users never evaluates that token. On-behalf-of access is the opposite: the person is the subject, and an agent-identity policy does not cover it. You need one policy per subject the agent actually uses, or the SaaS call you care about is the one you left open.
What happens if the agent calls the tool with an API key?
Conditional access does not see the call. The key never requests a token, so no policy runs. The gateway we put in front of tool use denies that pattern. Leaving the key in place and hoping the directory policy is "close enough" is how the agent keeps working during an incident you thought you had blocked.
Can one blueprint policy cover agents we add later?
Yes. A conditional access policy targeted at an agent identity blueprint applies to identities created from that blueprint, including identities created after the policy. That is the scope we prefer once the set of agents is growing. Individual targeting is how a new agent ships without the SaaS boundary.
Do interactive challenges work for an autonomous agent identity?
No. There is no person at the prompt, so the documented action for an agent that authenticates as itself is to block, using agent risk as the condition. We test in report-only, then enforce the block. We do not assign a user-style challenge and call the control done when the agent cannot complete it.
Does this replace least privilege on the tool?
No. Conditional access decides whether a token for that audience is issued to that subject, while the tool's own permissions still need to be narrow. A token that should never have been issued is the failure this gate is built to stop. A token that is too powerful inside an allowed application is the next control.
Discuss securing your agent identities before they call SaaS tools. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.