TL;DR: Shadow AI is spreading through unauthorized MCP servers, editor integrations, OAuth grants, and local tooling that security teams often do not see until they audit config files, logs, and tokens, according to Obot. The core issue is not detection alone, but the collapse of governance assumptions around agent access, data flow, and approval.
At a glance
What this is: This is a practical guide to finding shadow AI and unauthorized MCP servers, with the key finding that hidden AI tooling usually surfaces in config files, logs, tokens, and user outreach before teams see it in a formal inventory.
Why it matters: It matters because IAM and security teams need a way to govern AI tool usage, OAuth-granted access, and machine-connected workflows before those paths create uncontrolled data exposure and compliance gaps.
Context
Shadow AI here means AI tools, connectors, and MCP servers operating outside approved governance and visibility. In this article's framing, the operational problem is not whether teams can run these tools, but whether identity and access control can still explain who is using them, what they can reach, and why.
The article ties the issue to NHI governance because MCP servers, OAuth grants, and local editor integrations often create machine-access paths that sit outside normal approval and review flows. That makes the problem one of discovery, entitlement control, and lifecycle management rather than simple endpoint hygiene.
For IAM and security teams, the practical question is how to inventory hidden AI usage before it becomes normalised. The article's core message is that shadow AI is already inside many environments, and the first task is to make those access paths visible enough to govern.
Key questions
Q: What breaks when shadow AI and MCP servers are not governed centrally?
A: Local AI tooling becomes an unaudited access layer. Config files, tokens, and editor integrations can create durable connections to company data without a central approval record, which makes review, revocation, and ownership tracking inconsistent. The result is governance drift: teams can no longer explain where access came from or who should be accountable for it.
Q: Why do unsanctioned AI tools create compliance risk for IAM teams?
A: They move employee data into third-party systems that may sit outside approved access, logging, and retention controls. IAM teams are affected because identity determines who can submit data, from which device, and under what policy. When those conditions are unclear, compliance, auditability, and accountability all weaken at the same time.
Q: How do security teams know if shadow AI is actually under control?
A: Security teams know shadow AI is under control when they can inventory every agent, model workflow, and tool connection, then map each one to an owner and access scope. If they cannot explain who owns it, what it can access, and when it was last reviewed, it is not controlled.
Q: How should teams govern MCP servers once they are discovered?
A: Classify recurring MCP servers as managed access objects, not personal tooling. Put approved servers behind a shared control point, assign ownership, restrict who can use them, and remove direct local registrations that cannot be reviewed or logged. That approach keeps productivity while restoring observable access governance.
Technical breakdown
How shadow AI hides in MCP config files and local tooling
MCP clients commonly store server definitions in local configuration files, editor settings, or application-specific folders. That means the access path is often created on an endpoint long before it appears in any central platform record. In practice, the hidden control point is not the AI model itself but the local registration of the server, the command it launches, and the data source it can reach. This is why local file inspection is a discovery technique, not a governance model. Practical implication: treat local MCP configuration as identity-bearing infrastructure and inventory it like any other access surface.
Practical implication: inventory MCP configuration locations and tie them to approved server ownership.
Why DNS, proxy logs, and OAuth tokens reveal hidden AI access
Shadow AI leaves traces in outbound DNS, proxy traffic, and token inventories because the tools still need to authenticate, fetch data, and call external services. OAuth grants are especially important because they can create durable access links that bypass normal review, even when the tool itself looks harmless on the desktop. The technical issue is not just traffic volume but ungoverned authorization pathways that connect local tooling to enterprise data. Practical implication: correlate network destinations with OAuth app inventories to find AI access that never entered an approval workflow.
Practical implication: correlate network logs with OAuth app and token inventories to find unapproved AI access.
Why a gateway changes governance for MCP servers
A gateway centralises MCP traffic, which turns scattered local execution into a controlled access plane with logging, RBAC, and policy enforcement. That shifts governance from after-the-fact reconstruction to real-time visibility. It also changes the operating model for NHI oversight because the server becomes a managed access object rather than an unmanaged local habit. This is not a detection-only improvement. It is a boundary that can make AI tool usage auditable, revocable, and easier to normalise into ordinary access governance. Practical implication: move repeat-use MCP servers behind a governed control point before usage fragments further.
Practical implication: place repeat-use MCP servers behind a governed control plane before usage fragments further.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
- Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Shadow AI is now an identity governance problem, not just an AI discovery problem: the article shows that MCP servers, editor integrations, and OAuth-connected tools can spread without a formal approval step. That means access is being created outside the governance record, which breaks the assumptions behind entitlement reviews and application inventory. The practitioner conclusion is that AI usage must be governed as an access estate, not as an isolated productivity trend.
Local configuration is the new control plane for unauthorized AI access: the most telling places to inspect are config files, editor settings, and app-specific folders where MCP servers are registered. These files determine what runs, what it can call, and where it sends data. That makes endpoint configuration part of identity control, because the local server definition is effectively the policy boundary.
OAuth grants are the hidden persistence layer of shadow AI: once a token or connected app is present, the AI workflow can keep accessing enterprise data without looking like a formal system integration. That creates unreviewed, durable connectivity between users, tools, and services. Ephemeral user intent, persistent machine access: the governance model assumes that short-term productivity use is harmless, but the authorization it leaves behind outlives the session and becomes a standing access path. Practitioners need to treat grants as lifecycle objects, not one-time permissions.
Centralised MCP governance is becoming the practical boundary for the category: the article's gateway model reflects where the market is heading, toward loggable and policy-aware access mediation rather than endpoint-by-endpoint scavenger hunts. That does not remove the need for discovery, but it does reduce dependence on manual reconstruction. The implication for IAM teams is to re-evaluate where approval, logging, and revocation actually live in the AI tool chain.
The stronger signal is not more AI usage, but less visible AI usage: when employees adopt tools for convenience, control often shifts into informal channels that security teams do not monitor well. That pattern is familiar from shadow IT, but MCP and AI connectors move faster and leave more scattered artefacts. The practitioner conclusion is to assume hidden usage exists and build continuous discovery around it, not around periodic exceptions handling.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Shadow AI discovery needs to become continuous, not episodic: once MCP servers are created locally, periodic audits will miss the next wave of ad hoc tools. Security teams need a standing inventory process that combines endpoint inspection, traffic analysis, and connected-app review so hidden AI usage is surfaced before it hardens into routine access.
Local access paths are now part of the governance perimeter: editor settings, desktop integrations, and token grants are no longer peripheral artefacts. They are the operational layer where AI capability becomes enterprise access, so IAM teams should treat them as governed identity surfaces rather than convenience features.
The scale of the problem is visible in the wild: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to the State of Secrets Sprawl 2026. That is a strong signal that AI-related local configuration is already large enough to warrant routine discovery and revocation workflows.
For practitioners
- Inventory local MCP server registrations Scan known editor and desktop configuration paths for MCP server definitions, then map each server to an owner, purpose, and approved data source.
- Correlate outbound AI traffic with token inventories Review DNS and proxy logs for AI API destinations, then match the source machines to OAuth apps, personal tokens, and connected services that can reach internal data.
- Create a sanctioned MCP catalog Register the small set of MCP servers that people actually use, define group-based access, and retire ad hoc local registrations that bypass governance.
- Run a monthly shadow AI discovery cycle Re-scan endpoints, logs, and grants on a fixed cadence so new MCP servers, browser extensions, and AI-connected apps do not stay invisible for long.
Key takeaways
- Shadow AI is creating hidden machine-access paths that sit outside normal approval and inventory processes.
- Config files, logs, and OAuth grants are the practical starting points for discovery because they reveal how these tools actually connect and persist.
- Governance improves when repeated AI tooling is moved behind a controlled access plane with logging, ownership, and revocation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article repeatedly points to config files and tokens as discovery points for hidden AI access. |
| NHI-03 — Vulnerable Third-Party NHI | Unauthorized MCP servers and external AI connectors behave like unmanaged third-party identities. | |
| NHI-04 — Insecure Authentication | OAuth grants and connected apps can create unreviewed authentication paths into internal systems. | |
| Recommendation — Scan endpoint config paths and revoke any exposed or unapproved secrets tied to AI tooling. Inventory external AI connectors and require ownership before they can access enterprise data. Review connected-app authentication paths and remove grants that bypass normal approval. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article's hidden tokens and connected tooling are classic access enablers for movement and misuse. |
| Recommendation — Map token exposure and unauthorized connector use to credential access and lateral movement detections. | ||
Key terms
- Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
- AI Usage Inventory: An AI usage inventory is a record of all models, agents, copilots, and related tools in an environment, including their data access and permissions. It gives security teams the visibility needed to assign ownership, assess exposure, and govern shadow AI.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 6, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org