Managed Services

When Your "Trusted Location" MFA Bypass Meets an AI Agent

Every AI assistant your team plugs into Microsoft 365 is an OAuth consent decision. Here's what that looks like from the SOC chair, and why "is this a breach or just AI?" is the new normal.

Josh Gilbert

When Your "Trusted Location" MFA Bypass Meets an AI Agent
When Your "Trusted Location" MFA Bypass Meets an AI Agent

If you're running Microsoft 365 with a Conditional Access (CA) policy that skips MFA at a trusted location: congrats on making everyone's lives easier. You probably set that policy up years ago for a good reason, reducing MFA fatigue for people who are already behind enough security controls.

Then AI agents showed up.

I recently ran into this while rolling out Claude in an environment with MCP (Model Context Protocol) server connections. Think Claude reaching out to Microsoft 365, SharePoint, or whatever other LOB apps you use within your environment. The existing CA policy, built for humans logging in from a trusted network, didn't know the difference between "Josh signed into Outlook to read his vendor spam" and "Claude is calling the Graph API through an MCP connector from that same trusted location." It just saw the location match and waved the MFA requirement through.

Except users trying to add the 365-web connector via Claude were running into issues. Since they were in the office and authenticating to 365 via Anthropic, MFA prompts were being skipped, leading to broken connectors and sad faces all around. I probably got 3 pings and 2 at-desk visits within 10 minutes.

Why this happens

Conditional Access policies typically evaluate:

  • Who is signing in (user, group)
  • Where from (named location, IP range)
  • What they're accessing (application, resource)
  • How (device compliance, sign-in risk)

A location-based MFA bypass is usually scoped fairly broad. "Any app, this location, skip MFA." That's fine when the only thing authenticating from that location is a laptop with a human behind it. It gets messy the moment a service, script, or AI agent starts authenticating through the same network path or the same app registration and inherits a bypass it was never meant to have.

What we did

Scoped exceptions into the existing CA policy. We added explicit exclusions for the MCP server / app registrations tied to the Claude integration. The trusted-location bypass now applies only to the human sign-ins it was originally designed for.

Built a new, dedicated CA policy for the AI integration. This one requires MFA (or another strong auth signal, depending on the app) specifically for the MCP connections. Regardless of location, regardless of the old exemption. AI agent traffic gets its own lane.

Left the door open to tighten further. Once the policy is scoped correctly, it's much easier to layer on things like device compliance checks or risk-based sign-in requirements for the AI-specific policy without touching anything else.

The bigger lesson

This wasn't really a Claude problem or an MCP problem. It was a policy hygiene problem that happened to surface because a new kind of identity (an AI agent, authenticating like a service but sometimes routed like a user) came in and didn't behave the way the CA policy assumed it would.

If you've got trusted-location MFA bypasses in your tenant, it's worth asking yourself: what else is authenticating through that path right now, and did it earn the exemption, or did it just inherit it?

This is the same pattern that surfaced when an MCP server tripped our EDR earlier this year. Different control, same root cause: AI integrations behave like a new kind of identity, and policies scoped for humans don't quite fit them.

Takeaways for your environment

  • Audit your trusted-location bypasses. List everything currently authenticating through those locations or app registrations.
  • Give AI and automation integrations their own CA policy. Don't let them inherit exemptions built for people.
  • Treat unexpected MFA prompts as a diagnostic. If something asks for MFA when your policy says it shouldn't have to, that's worth a five-minute look before you dismiss it.

Want help auditing your Conditional Access?

Reach out and we'll walk through your Conditional Access policies for gaps like this, before an AI integration (or anything else) finds them for you.

Talk to us about managed services arrow_forward

Josh Gilbert is on the managed services team at Springthrough, where he spends his mornings deciding whether things are on fire or not.

Share this post