Shadow AI Is an IAM Problem Now, Not a DLP Problem

Key points

• Shadow AI has shifted from a data leakage concern to an identity and authorization problem.
• AI agents are accumulating OAuth tokens and service-account keys with scopes far wider than they need.
• Long-lived refresh tokens issued to AI plugins carry no rotation policy and no device-posture binding.
• Conditional access policies that fire at login don't fire again when an agent calls an API at 3 a.m.
• The fix is standard IAM hygiene applied to a new class of principal, not a new product category.

Is this still a DLP story?

The first wave of shadow AI panic was about copy-paste. Someone drops a customer list into a public chatbot, security writes a policy, DLP gets a new regex, the CISO sleeps. That was 2023, and it made sense then.

The problem has moved. What sits inside enterprises now isn't an employee with a browser tab. It's a sprawl of AI assistants and home-grown agents holding OAuth tokens, service-account keys, and delegated access to email, code repos, ticketing systems, and CRM data. Shadow AI stopped being a data leakage story. It became an identity and authorization story. We tracked the budget consequences of exactly this shift in our 28 May piece "AI Agent Identities Are Redrawing Enterprise IAM Budgets".

Should you worry about authentication or authorization?

Authentication asks who is calling. Authorization asks what they're allowed to touch. Most AI integrations being stood up by product teams answer the first question well enough, the user logs in via SSO, and answer the second with a shrug. The agent gets the user's scopes. Sometimes it gets more, because the integration was built against an app registration with broad read-write permissions when narrower read-only access would have done.

That's an OAuth consent problem, and a long-standing one.

What patterns keep appearing?

Four show up repeatedly in incident reviews:

• Long-lived refresh tokens issued to AI plugins, with no rotation policy and no binding to device posture.
• Service principals created for "the AI thing" that accumulate role assignments over months because nobody owns the cleanup.
• Agent frameworks that cache user tokens in plaintext on developer laptops so the orchestration can replay calls.
• Consent phishing aimed squarely at AI tool sprawl, where a malicious app asks for the same scopes a legitimate copilot would.

The last pattern is particularly sharp given what we reported on 29 May: vibe-coded internal tools graduating to public URLs with identity stacks that never see them coming.

Would MFA have helped?

Mostly no. The user already authenticated. The token in the agent's hands was issued legitimately. What was missing was scope minimization, token binding using mutually authenticated TLS, and continuous evaluation. Conditional access policies that fire at login don't fire again when an agent calls a cloud API at 3 a.m. From a datacenter IP.

What should teams actually do?

The fix isn't a new product category, whatever vendors at Identiverse told you. It's boring IAM hygiene applied to a new class of principal:

1. Treat every AI agent as a non-human identity with its own lifecycle and owner, reviewed on a set cadence.
2. Issue narrow scopes. Audit consented scopes monthly. Revoke aggressively.
3. Require short-lived tokens with sender-constrained binding wherever the platform supports it.
4. Log the authorization decisions, not just the authentications, and pipe them somewhere a human will actually read.

DLP still has a job. It's just not the one that matters here. The vendors pushing new AI-security platforms are selling a tidy story; the actual work is unglamorous consent hygiene and lifecycle management for principals that most identity stacks weren't designed to track. Watch whether the non-human identity governance space can deliver on that, because right now the gap between the pitch and the tooling is wide.