The Agents Entra Can’t See: Detecting and Preventing Rogue AI

Talk about AI and agents has swept the tech industry for the better part of a year, and organizations have shifted from “how can we leverage AI” to “how can we control it.” Microsoft now steers agent integration through Entra Agent ID and Copilot Studio, and vendors like Anthropic are moving the same way with M365 connector applications. But your tenant may have already onboarded agents before that flow existed. Worse, a few paths let rogue AI show up unnoticed.

The biggest risk isn’t registered agents in Entra but agents operating through legitimate user identities and trusted devices. Start by fixing identity hygiene and endpoint visibility before investing in AI-specific controls. This article walks through three examples of how unmanaged agents are possible and how to detect and prevent each.

User consent remains the easiest way to introduce rogue AI

Microsoft has spent the last year securing the user consent workflow, requiring admin consent for the most dangerous permissions. By default it uses a deny list of mostly read-write scopes, but users can still consent to read-only scopes like User.Read, openid, profile, and email. The most dangerous user-consentable scope for AI is offline_access, which hands the agent a refresh token, and with it persistent background access.

This path registers a discoverable service principal and consent record giving opportunity for detection. Review application consent history and end-user consent logs for past misuse. Prevention of this path is even simpler. Lock down user consent entirely and route everything through the admin consent workflow.

Tokens: Not every rogue agent creates an Entra footprint

The next path is a user-led, programmatic flow that yields a token. In plain terms, the user hands the agent a username and password. The key difference from the user consent path is the agent borrows a built-in first-party application so no service principal or consent record is created at all. Entra just sees a normal user sign-in.

A few variants matter. OAuth 2.0 Resource Owner Password Credentials (ROPC) is a legacy single-factor flow. The defense is multifactor authentication (MFA). Always MFA, all the time.

The device-code flow is closed with a simple Conditional Access policy.

Last is the Family of Client IDs (FOCI): a token issued for one family client is reusable across all of them, and there’s no toggle to disable it. Per-app Conditional Access is trivially bypassed, so mitigation shifts to detection: revoke tokens on suspected misuse and lean on Continuous Access Evaluation, though its coverage isn’t universal.

Trusted devices are where identity controls stop helping

The most interesting scenario is a workstation dedicated to AI: the brand-new Mac Mini on someone’s expense report. The employee adds it to the tenant via hybrid join or as a compliant device, and once joined it obtains a TPM-bound Primary Refresh Token(PRT). The agent runs as that user and silently asks the Web Account Manager (WAM) broker for tokens, a persistent, always-on connection.

This is the hardest of the three to close. The agent passes every Conditional Access check because it genuinely is the user, on a trusted device. Token Protection binds tokens to the device, but it can’t separate “the user” from “an agent process running as the user” on that same machine.

Prevention starts with not letting users join their own devices, backed by strong compliance Conditional Access Policies (CAPs). Detection must move to the endpoint. Defender for Endpoint advanced hunting over DeviceProcessEvents (headless-browser flags, unexpected child processes) and DeviceNetworkEvents (a local process reaching an external AI API), plus blocking unsanctioned apps through Defender for Cloud Apps.

Identity hygiene still eliminates most rogue AI risk

The whole point here is to cut through the AI noise and get back to basics. Entra hygiene that’s years old already closes most of these scenarios:

• Set user consent for applications to Do not allow user consent
• Enable the admin consent workflow
• Enforce MFA everywhere, all the time via Conditional Access
• Block device-code flow with a Conditional Access policy
• Limit users’ ability to join devices to Entra
• Enforce device compliance via Conditional Access

Basic configuration can’t catch everything. Some scenarios slip through, and what can’t be mitigated must be detected. That means moving beyond the identity plane toward device-based detection. “But what about Purview?” Purview is where a lot of agent control is heading, and it’s genuinely useful, but it isn’t the end-all-be-all.

Data Security Posture Management (DSPM) for AI is visibility, not enforcement; you still configure DLP and Insider Risk yourself. Its monitoring of third-party AI leans on the same onboarded endpoints and browser extensions this article already pushed. The richer feature set sits behind premium licensing, and label-based protection is blind to unlabeled data. Treat data protection as a backstop, not the front door. Start with the basics and give yourself some defense in depth.

If your security strategy depends on identifying agents in Entra, you’ve already missed the most difficult class of AI risk. Assume some agents are operating as users and design your controls accordingly.