In depth
Shadow AI covers any AI use outside the organization’s approved, governed paths: a chatbot used with a personal account, a coding agent running with an individual API key, an MCP server a developer added to a local config file, an MCP config committed to a repository, or an AI browser extension. Some of it is visible on the network, as connections to model provider endpoints. Much of it is not. A local MCP server talks to its client over pipes and opens no socket, and a coding agent’s tool calls happen inside a process on the laptop. Finding shadow AI therefore takes several vantage points together: gateway traffic, network destinations attributed to the app that opened them, and an agent on the device that reads AI client configurations and detects installed AI tools.
Why it matters
You cannot govern what you cannot see. Policies, approvals and audit trails built on gateway traffic cover only the AI that goes through the gateway. Shadow AI is where data leaves without a record and where an unreviewed tool runs with a developer’s full privileges. It is also what an auditor finds when asking for an inventory of AI systems. Discovery turns shadow AI into a list of decisions: approve and route it through the gateway, or quarantine and block it.
Common use cases
- Inventorying AI apps and agents installed across managed devices
- Finding locally configured and repository-committed MCP servers
- Attributing AI network destinations to the app that reached them
- Quarantining unapproved local MCP servers until they are reviewed
- Producing a complete AI systems inventory for audit
How Ferentin handles it
Ferentin is the trust layer for AI agents. The platform centralizes identity, policy enforcement and audit across LLMs, MCP servers and AI tools. Shadow AI is one of the primitives this trust layer is designed around. See the platform overview for how it fits into the service edge, control plane and observability plane.