Your AI Risk Policy Is Protecting the Wrong Thing

Every CISO I've worked with this year has a policy for what employees can paste into ChatGPT. Almost none have a policy for what the AI itself can access.

I watched a client walk me through their meticulously documented AI acceptable use policy last month. Twenty-three pages covering prompt injection risks, data classification matrices, approved use cases by department. They'd trained 800 employees. Built a submission workflow for new AI tool requests. Real work, thoughtful work.

Then I asked to see their register of what credentials their AI agents currently held.

Silence.

The threat moved while we were writing the policy manual. For the past year, the enterprise security conversation around AI has centered on prompts—what employees type into input boxes, whether proprietary code leaks into training data, whether customer PII ends up in someone's corpus. Those are real concerns. We built reasonable guardrails. But we've been so focused on what goes INTO the AI that we've lost track of what the AI can already SEE.

The OAuth Blindspot Nobody's Mapping

When your developer connects Claude to their development environment, they're not just asking questions anymore. They're granting persistent access. When an AI agent receives an OAuth token, you've handed it scoped, often-undocumented, session-surviving access to whatever that SaaS account can read.

Last month, Claude Code OAuth tokens were stolen via MCP server hijacking. Separately, Braintrust urged organization-wide AI provider key rotation after an AWS account compromise. Two named incidents in thirty days. Same systemic pattern: the AI didn't break by saying the wrong thing. It broke by quietly accumulating credentials nobody had inventoried.

Your risk policy covers prompt injection. Your AI doesn't need prompt injection—it reads your Salesforce, your GitHub, your customer database, your financial reporting system. With credentials you approved, one OAuth popup at a time, with no centralized ledger of what was granted to what.

We've Seen This Movie Before

The 2010s taught us this lesson with cloud SaaS adoption. Finance teams moved to Xero, NetSuite, Workday. Sales moved to Salesforce. Every department spun up their own tools. IT discovered the sprawl two years later when they tried to offboard a departed VP and found nineteen active integrations nobody had documented.

Nobody gets breached the day the integration goes live. The exposure just slowly accumulates until someone goes looking.

We solved it with SSO rollouts, centralized identity management, service account audits. Painful, expensive, boring work. The controls worked—not because the technology was magical, but because we finally had inventory and governance around WHO had access to WHAT and WHY.

AI is replaying that cycle at 3x speed. Developers are connecting MCP servers. Marketing is linking AI tools to campaign platforms. Finance is authorizing AI analysis of transaction data. All legitimate use cases. All generating credential grants that live somewhere between "officially sanctioned IT project" and "completely off the books."

The question stopped being "what can our people type into this thing." It became "what can this thing already see, and what paperwork says it shouldn't."

The Inventory Problem Is The Security Problem

I was on a call last week with an audit partner reviewing AI governance frameworks. Smart guy, thorough documentation. When I asked how his firm would evidence AI credential scope minimization during an audit, he paused. "We'd... ask IT for the list?"

What list? There's no universal dashboard showing every OAuth grant to every AI service across your SaaS estate. Microsoft Entra shows you some of it. Okta shows you part of it. Your developers' local MCP configs? Those live in dotfiles nobody's aggregating. Your marketing team's Make.com workflows connecting GPT-4 to HubSpot? Probably not in any IT asset register I've seen.

You can't protect what you haven't inventoried. And right now, most organizations couldn't produce a complete register of AI credentials if their cyber insurance renewal depended on it—which, increasingly, it will.

What The 2010s SSO Playbook Teaches Us

For finance and audit leaders trying to map AI risk to existing control frameworks: you don't need to invent new controls. You need to apply the ones that worked for SaaS sprawl.

Credential custody. Who issued the token? To which AI service? With what scope? Who can revoke it?

Scope minimization. Does the AI agent really need read/write, or would read-only suffice? Does it need access to all records, or just the subset relevant to its function?

Rotation evidence. When was the credential last rotated? What's the maximum lifetime policy? Can you prove compliance during audit?

Access audit trails. Who connected what to which model, when, and under what authorization? If an API key leaks, can you reconstruct blast radius?

These aren't exotic controls. They're IAM 101. The novelty isn't the framework—it's forcing yourself to treat AI agents as service accounts, not as "tools employees use." Because once that OAuth token is granted, the AI is an account. With permissions. That persist. That need governance.

The Uncomfortable Middle

Here's the part nobody wants to hear: you probably can't lock this down completely without breaking legitimate work. Developers need AI coding assistants connected to repos. Sales needs AI summarizing customer conversations from CRM data. Finance needs AI analyzing transaction patterns.

The correct answer isn't "ban AI access to internal systems." It's "inventory what access exists, apply least-privilege principles, and audit it on the same cadence as your service accounts."

But most organizations are still at "we don't actually know what's connected."

I don't have a magic bullet for you. I've watched four technology disruption cycles in my career—client-server, web apps, mobile, cloud. Every single time, the early security conversation focused on the NEW risk while missing the BORING risk. We obsessed over SQL injection while ignoring service account sprawl. We built WAFs while ignoring SSO governance. We're doing it again.

What To Do Monday Morning

If you're a CISO, audit partner, or finance leader trying to get your arms around this:

Start with the inventory. You can't mature what you can't measure. Build a register—spreadsheet, Notion doc, whatever—of known AI integrations that hold credentials. Service name, connected systems, scope granted, business owner, date authorized. It'll be incomplete. That's fine. Start.

Map it to existing IAM policies. You already have service account governance. Extend it. AI agents with OAuth tokens should appear in the same review cycle as API keys, database credentials, and service principals.

Ask your SaaS vendors what their AI agents can see. Salesforce Einstein, Microsoft Copilot, Google Workspace AI—these come with your enterprise subscriptions. What access do they have by default? Can you scope it down? Do you have audit logs of what they've touched?

Pressure your identity provider. Okta, Entra, Ping—they're seeing this pattern too. Ask them for better visibility into AI OAuth grants. The vendors who solve "AI credential inventory" will win enterprise spend over the next 18 months.

Update your acceptable use policy. Not the prompt policy—the credential policy. Make clear that connecting an AI service to internal systems requires the same authorization workflow as provisioning a service account. Enforce it in onboarding, offboarding, and quarterly access reviews.

The controls aren't complicated. The discipline is. We perfected the prompt injection threat model while forgetting that AI doesn't need to trick your employees if it already holds the keys.

What does your firm's AI credential register look like—and is anyone reviewing it on the same cadence as service-account access?

If the answer makes you uncomfortable, you're ahead of most organizations I'm talking to. But only slightly.