Shadow AI Management Best Practices: The Layer Most Frameworks Skip
Published:
Last Updated:
On May 7, 2026, a compliance officer at CB Financial Services determined that a bank employee’s use of an unauthorized AI tool to process non-public customer records had crossed a threshold. The records included names, Social Security numbers, and dates of birth. Four days later, on May 11, the company filed a Form 8-K under Item 1.05, the SEC’s rule for material cybersecurity incidents. No external attacker was involved. No systems were breached. The company’s own reasoning was blunt: the volume and sensitivity of the exposed data made the incident material on its own, independent of whether anyone downstream ever misused it.
The tool wasn’t hacked. It was used by an employee, for ordinary work, outside any process the company had approved.
As far as public filings show, this is the first Form 8-K triggered by unauthorized AI use rather than an external attack. It will not be the last. Shadow AI, defined and mapped in full elsewhere in this series, refers to unauthorized AI tools and personal AI accounts running against company data without security or IT oversight. It is not a new category of insider risk so much as the AI-era version of shadow IT, unsanctioned software employees adopt without approval, except this time the unapproved tool can read, summarize, and forward whatever customer data, financial records, or trade secrets it is handed, sometimes into a model’s training data on the other end, depending on the vendor’s terms. IBM’s 2025 Cost of a Data Breach report puts a number on that gap: organizations with high levels of shadow AI paid $670,000 more per breach on average than organizations with little or none, a figure we’ve covered in depth in our piece on Shadow AI Risks. The risks of shadow AI compound quickly once agents start acting on that access rather than just processing it, and the exposure isn’t limited to the kind of compliance violations that show up in a regulatory compliance audit; it’s the ordinary use of AI at work, unremarkable until it isn’t.
Most organizations working on this problem already have a framework. Fewer have noticed that the framework has a hole in it, and the hole is exactly where AI adoption is growing fastest.
A disclosure before going further: Obot is our platform, and it’s built for the MCP and agent layer this article argues most frameworks skip. We cover where it fits right after mapping that gap, and we’re explicit about what it doesn’t cover.
The Five-Phase Framework Most Guidance Already Gets Right
The strongest published treatment of shadow AI management organizes the work into five phases: Discover, Govern, Protect, Educate, and Measure. Discover means finding unapproved AI tools, from generative AI tools an employee signed up for personally to AI-powered features quietly switched on inside software the company already licenses, through OAuth grant audits, browser extension scanning, network telemetry, and employee surveys. Govern means AI usage policies, a fast-lane approval process for low-risk tools, and a cross-functional review committee for higher-risk ones. Protect means browser-native monitoring and real-time intervention when someone tries to paste sensitive data into an unapproved tool, whether that’s tools like ChatGPT or a narrower artificial intelligence tool built for one department. Educate means just-in-time coaching at the moment of risky behavior rather than annual training. Measure means tracking adoption, incident, and time-to-approval metrics that a board can actually read.
This structure is a reasonable floor. It covers industry-specific incident patterns across healthcare, financial services, and legal, it gives boards a KPI vocabulary instead of a vague risk narrative, and it accounts for the 2026 shift in cyber insurance underwriting: several major carriers, including W.R. Berkley, Chubb, Travelers, Berkshire Hathaway, and AIG, have adopted ISO’s generative-AI exclusion endorsement (form CG 40 47 01 26, effective January 2026, already logged on 2,369 policy records across 49 states by mid-2026), which carves AI-related bodily injury, property damage, and advertising-injury claims out of standard commercial general liability coverage. An organization that can’t demonstrate a working shadow AI governance program is increasingly an organization paying for insurance that won’t pay out.
None of that is wrong. Across roughly 9,000 words, that treatment covers industry incident patterns, board reporting, and the insurance shift in real detail. The problem is not what it says. It’s what it assumes about where AI usage happens: everywhere in that framework, “AI tool” means something with a login screen.
The Assumption Baked Into “Discover,” “Govern,” and “Protect”
Read the phase descriptions again, more closely. Discover means auditing OAuth grants and scanning for browser extensions, both of which exist because someone signed into something. Govern means an acceptable-use policy and an approval committee, both of which exist because someone submitted a request for a specific named tool. Protect means browser-native monitoring and real-time intervention, both of which exist because the risky action happened inside a browser window where a DLP agent could see it.
Every one of those mechanisms depends on a moment of visible authentication or a visible interface. A marketing employee who signs up for a consumer writing tool with a work email produces an OAuth grant. A developer who installs a browser extension that quietly forwards page content produces a detectable browser event. Both of those are real security risks, and both are well covered by the standard toolkit’s access controls and security controls.
Neither of those mechanisms produces anything when a developer runs npx to start a local MCP server that connects an agent framework to a production database, sending its own API calls straight past every browser-based control. There’s no login screen. There’s no browser tab. There’s no SaaS admin console with a user list to audit. There’s a process, running locally or in a CI pipeline, holding a credential that was probably copied from a .env file, doing exactly what it was told, invisibly, because nothing in the standard toolkit for unsanctioned AI tools was built to look for a standing local process instead of a session. This is precisely where shadow AI activity goes to hide.
Where the Framework Runs Out: The MCP and Agent Layer
A Model Context Protocol server is not a browser session and not a SaaS account. It is a standing local process, often started by a developer with a single command, holding its own API keys and file-system or database access to AI models and other enterprise AI tools, running quietly on a laptop or a CI runner with no OAuth grant to audit and no browser extension to flag. The mechanics of why this vector is functionally invisible to standard detection tooling are covered in full in Shadow MCP Servers; the short version is that the entire discovery layer most frameworks rely on was built for a different threat model, one where “unsanctioned tool” and “unsanctioned login” meant the same thing, not for shadow AI systems that never touch a login screen at all.
This is not a hypothetical gap. It is the same structural blind spot found across the current AI governance content landscape: a review of a widely cited detection-tools roundup found it recommending browser and SaaS-focused tooling for a threat that, by the time it reaches production, is running as AI agents and MCP connections that no browser-based control will ever see.
The fix isn’t a rival framework. Discover, Govern, Protect, Educate, and Measure are still the right five verbs. What changes is the object of each verb. The table below lines up what each phase means at the browser and SaaS layer against what the same phase has to mean at the MCP and agent layer.
Comparison matrix
Phase
Browser / SaaS layer
MCP / agent layer
Measure
Adoption, incident, and time-to-approval KPIs
Separate identity-sprawl and context-sprawl KPIs, not one blended "agent count"
Educate
Just-in-time coaching when an employee tries a risky paste
Same coaching, extended to developers wiring up agent and MCP connections
Protect
Browser-native DLP, real-time paste interception
Credential brokering (short-lived, scoped tokens) and tool-call audit logging at the gateway
Govern
Acceptable-use policy, review committee for new SaaS tools
Self-serve catalog of pre-approved MCP connections, fast enough that developers don't route around it
Discover
OAuth grant audits, browser extension scans, network telemetry
Device and CI/CD scans for running MCP processes and config files referencing MCP endpoints
The Infrastructure Response
The generic answer to “how do we manage shadow AI” is still the five-phase framework: Discover, Govern, Protect, Educate, Measure, with a sixth lens, the MCP and agent layer, applied across all five rather than treated as a footnote under Discover and Govern.
Obot implements that sixth lens as one of several AI services a security team needs when integrating AI governance across a real environment. It’s built as an Enterprise AI Control Plane around three jobs, define what agents can reach, choose where they run, and prove what they did, and each maps onto the phases in the table above. That is not a claim to solve AI governance end to end, and it isn’t a substitute for the browser and SaaS AI solutions already covering the rest of the stack. It is the piece that closes the specific gap this article walks through: the layer where OAuth audits and browser extensions cannot see, and where shadow MCP servers and unmanaged AI agents currently operate with the least oversight of anything in the modern AI ecosystem.
Gateway: Govern and Protect With Obot MCP Gateway
Obot MCP Gateway is an MCP gateway with AI capabilities for visibility and control: a self-serve catalog of approved MCP servers so developers have a faster sanctioned path instead of a reason to route around one, credential brokering so agents never hold standing API keys, and a log of every tool call for audit. It’s open source under the MIT license, self-hostable on Kubernetes or Docker, and available as a managed service. Since v0.27, Okta SCIM provisioning revokes access automatically when someone leaves.
Device: Discover With Obot Sentry
The Discover row of the table calls for device-level scanning, and that’s what Obot Sentry does. It scans AI client configurations on developer machines, including Claude Code, Claude Desktop, Codex, Cursor, and VS Code, and reports which MCP servers, skills, and plugins each one loads, and for Claude Code, Codex, and Cursor it can fail closed on servers that aren’t approved.
Hosted: Contain With Claude Environments
For agents that shouldn’t run on a laptop at all, Obot v0.27’s Claude Environments run Claude Code under the same control plane, so the agent’s connections come from policy rather than a credential copied from a .env file.
Discover: What “Inventory” Actually Means at the MCP Layer
Inventory at the browser and SaaS layer means OAuth grant audits and login telemetry, because the thing being inventoried always authenticates somewhere. Inventory at the MCP layer means something closer to traditional endpoint and configuration scanning: device-level scans for running MCP server processes, CI/CD pipeline manifests that reference MCP endpoints, and repository scans for configuration files that wire an agent framework to an external tool. None of that shows up in an identity provider’s logs, because none of it necessarily involves a human logging into anything after the initial setup.
The practical difference shows up in what a security team and IT teams actually have to go looking for to monitor AI usage properly. A browser-and-SaaS discovery process can run largely on data the company already has: SSO logs, extension inventories pushed from managed browsers, DNS query logs. An MCP-layer discovery process has to reach into places that data doesn’t cover, developer laptops, build pipelines, and repositories, because that’s where new AI tools and unauthorized AI tool use actually show up first. The full detection methodology, including the specific signals that distinguish an approved integration from an unsanctioned one, is covered in How to Detect Shadow AI. The addition specific to this layer is simply this: if discovery stops at identity-provider logs, it will produce a clean report on a program that still has shadow AI incidents waiting in an unmonitored MCP server running in production, and the report will be wrong in the direction that matters most.
Govern: Why an “Approved Tools Catalog” Means Something Different for Agents
Standard governance guidance calls for an acceptable-use policy and a fast-lane approval process for low-risk tools. That principle holds at the MCP layer, but the mechanics change. A marketing employee asking to try a new SaaS writing tool can tolerate a week of review; the tool isn’t blocking their work in the meantime. A developer who needs an agent connected to a database or a critical business function like a ticketing system to finish a sprint task is not going to wait three weeks for a review committee. They will wire up a local MCP connection themselves, using whatever credential is fastest to grab, and build their own AI solution on top of it. That is exactly how shadow AI emerges and produces incidents like the one CB Financial Services disclosed: not malice, just someone choosing the fastest available path to finish their work.
Governance for agent and MCP tooling has to function as a fast, self-serve catalog of pre-approved, centrally managed connections rather than a slower approval gate bolted onto a process built for SaaS procurement. In practice that means a developer can request access to an approved MCP server and get a scoped, working connection the same day, without ever touching a raw credential directly. This is the same pattern behind every shadow AI trend we’ve documented, and it’s central to how any team should manage AI risks: a banned or slow-to-approve path does not eliminate demand, it pushes the same demand underground where nobody can see it. Governance that wins the speed argument is the only governance that actually gets used.
Protect: Centralized Credential Brokering as the MCP Equivalent of Browser Monitoring
At the browser layer, protection means real-time DLP and session monitoring, catching the moment someone pastes a customer record into an unapproved chat window, the classic path to data leakage and data security incidents involving sensitive company data. That model depends on a human performing a visible action inside a monitored surface. There is no equivalent moment at the MCP layer: an agent doesn’t paste anything, it makes API calls, and the call either succeeds or it doesn’t, with nothing resembling a DLP prompt in between.
The equivalent control at that layer is credential brokering and tool-call audit logging. Every MCP connection routes through a gateway that issues short-lived, scoped credentials instead of handing an agent a standing API key, so a compromised or misbehaving agent can only reach what its current, narrowly scoped token allows, for as long as that token is valid. Every tool call the agent makes is logged the way a privileged human session would be, with the same expectation that it can be reconstructed after the fact. Same phase, same intent, protect the sensitive action as it happens, but the enforcement point moves from a browser extension to the gateway sitting between every agent and every tool it can reach.
Educate and Measure, Briefly
Educate and Measure need less adaptation than the first three phases, but they need one addition each. Educate still means just-in-time coaching over annual training, teaching people to use AI securely rather than reciting a policy they’ll forget, and the content just has to extend to developers wiring up agent tooling, not only employees pasting text into chat windows. A developer who’s about to hardcode a database credential into an MCP config file is a better coaching moment than a slide deck they saw in January. For organizations with EU exposure, this phase is no longer discretionary: Article 4 of the EU AI Act, in force since February 2, 2025 and softened by the Digital Omnibus in July 2026, requires providers and deployers to take measures supporting AI literacy among staff who operate AI systems, proportionate to their technical background and the context in which those systems are used. AI governance policies that stop at a signed acknowledgment form don’t satisfy that bar, and developers connecting agents to internal MCP servers are squarely among the staff dealing with the operation and use of AI systems that the obligation is written for.
Measure still means board-readable KPIs that support real risk management, but a single “agent count” metric hides more than it reveals, and blended metrics are how shadow AI deployments go unnoticed inside a program that looks healthy on paper. Identity sprawl (how many non-human credentials exist across the environment) and context sprawl (how much a single agent’s active permissions have accumulated over time, often well past what its original task required) are separate failure modes with separate remediations. A program can hold identity sprawl flat by deleting old service accounts while context sprawl quietly grows underneath, because nobody is measuring the second axis at all. Conflating both into one blended “agent count” is how a program ends up reporting a stable metric to the board while its actual exposure grows. The full two-axis framework for measuring both, and what to do once a number looks wrong, is in Agent Sprawl: Identity vs. Context Sprawl.
Closing the Layer That Doesn’t Show Up in a Browser
A program that fully closes browser and SaaS-based shadow AI exposure, complete with OAuth audits, DLP, and a fast-lane approval process, can still be structurally blind to the fastest-growing part of the problem. That is not because the program is poorly run. It is because the fastest-growing part of the problem doesn’t show up in a browser tab or a SaaS admin console at all. It shows up as a process running on a developer’s laptop, a config file in a CI pipeline, and a credential nobody remembers issuing. Closing that gap doesn’t require a different framework. It requires applying the one that already works to a layer most guidance never reaches.
Every agent under policy. Every action on record. Bring MCP and agent connections under the same governance, credential brokering, and audit logging as the rest of your AI stack. See Obot in action.
FAQs
What are the best practices for managing shadow AI?
The strongest published guidance organizes shadow AI management into five phases: discovering unsanctioned tools, governing their approval, protecting data in real time, educating employees at the point of risk, and measuring program effectiveness with board-readable KPIs. The gap in most versions of this framework is that all five phases are built around browser and SaaS-based AI tools and don’t extend to MCP servers or autonomous agents, which require the same five phases applied through device-level scanning, self-serve tool catalogs, and credential brokering instead of OAuth audits and browser monitoring.
Where does Obot fit in shadow AI management?
At the MCP and agent layer. Obot Sentry handles discovery on developer machines, Obot MCP Gateway provides the approved catalog, credential brokering, and tool-call audit logging, and Claude Environments keep agents off laptops entirely. Browser and SaaS tools still cover the rest of the stack.
OAuth audits and browser extension scanning are built to detect a browser session or a SaaS login. An MCP server is neither. It’s a standing local process, often started with a single command on a developer machine or CI runner, holding its own credentials with no OAuth grant and no browser extension involved. Standard discovery tooling has no signal to detect against.
What is the five-phase shadow AI framework?
Discover, Govern, Protect, Educate, and Measure. Discover finds unsanctioned tools through audits and telemetry. Govern sets policy and an approval path. Protect intervenes in real time when sensitive data is at risk. Educate coaches employees at the moment of risky behavior. Measure tracks the program’s effectiveness with metrics a board can read.
How do you discover shadow MCP servers specifically?
Through device and configuration-level scanning rather than identity-provider logs: scanning developer machines and CI/CD systems for running MCP server processes, and scanning repositories and pipeline manifests for configuration files that wire an agent to an external MCP endpoint. Obot Sentry covers the developer-machine side by reading AI client configurations. The full detection methodology is covered in How to Detect Shadow AI.
Has shadow AI ever caused a public regulatory disclosure?
Yes. CB Financial Services filed a Form 8-K under SEC Item 1.05 on May 11, 2026, after determining that an employee’s use of an unauthorized AI tool to process customer names, Social Security numbers, and dates of birth was material based on the volume and sensitivity of the data alone, with no operational disruption or external breach involved.
Do blanket AI bans actually reduce shadow AI risk?
Not on their own. A ban or a slow approval process doesn’t eliminate the underlying demand for faster tooling, it pushes that demand underground where it’s harder to see and govern. The programs that reduce shadow AI risk most effectively pair policy with a genuinely faster sanctioned path, not just a stricter unsanctioned one.
How is governing agent-based shadow AI different from governing browser-based shadow AI?
Browser-based governance relies on acceptable-use policy paired with a review committee for new SaaS tools, since approval friction there is tolerable. Agent and MCP-based governance needs to function as a fast, self-serve catalog of pre-approved, centrally managed connections, because developers who face a multi-week review will simply wire up their own connection rather than wait.
What should a shadow AI policy cover for developer and agent tooling specifically?
It should name MCP servers and agent frameworks explicitly rather than leaving them implied under general “AI tools” language, define who can approve a new MCP connection and how quickly, require credential brokering rather than standing API keys for any agent-to-tool connection, and set audit logging as a default rather than an opt-in for teams that ask for it.
