Shadow IT was always a governance problem. You couldn't govern what you couldn't see, and users have always found ways to work around sanctioned tools. But shadow IT was mostly about data at rest: files synced to unauthorized cloud storage, spreadsheets emailed to personal accounts. The blast radius was limited by what could be copied.
AI agents are different. They don't just store data. They act. They read your codebase, call APIs, execute shell commands, connect to external services. A shadow AI agent isn't a file sitting in the wrong place. It's an unsanctioned identity with production credentials taking actions on your behalf.
You can't govern what you can't see. Discovery is the foundation.
The Three Gaps
Most organizations think they know what AI agents are running in their environment. They have a list of approved tools. Maybe a sanctioning process. Often a spreadsheet.
Then they look closer.
The first thing they find is that the list is longer than expected. Approved Copilot, yes. But also Claude Code on twelve developer machines, Cursor on eight, Windsurf on three. Continue and Cody scattered across the engineering org. Aider on a contractor laptop that IT has never touched.
The second thing they find is that a sanctioned agent doesn't mean a sanctioned session. A developer runs Claude Code, the agent you approved, but logs in with a personal Anthropic account instead of the enterprise subscription. The agent is sanctioned. The session is ungoverned. Your policies don't apply. Your audit trail doesn't capture it.
The third thing, which takes longer to surface, is that running an agent is one thing and knowing how it's configured, what it connects to, and whether those connections are governed is entirely another. An agent with three MCP servers you approved and one you've never seen is a different risk profile than an agent running only the approved set. The difference is invisible until you go looking for it.
Discovery closes all three gaps.
Catalog-Level Discovery: What's in Your Environment?
Ceros maintains a recognition catalog, a Bill of Materials of known AI agents, MCP servers, and LLM providers. Beyond Identity curates the global catalog and updates it as the ecosystem evolves. You can extend it with custom entries for internal tools.
When you deploy the Ceros agent to your fleet, the Inventory page populates automatically. No manual cataloging. No spreadsheet audits.
For every enrolled device, Ceros discovers installed agents matched against the catalog by binary, version, and cryptographic checksum (a tampered or unofficial build stands out immediately), running sessions showing which agents are active right now and whether those sessions are sanctioned or running outside governance, session state including how long it has been running and what providers it is connecting to, and trends showing first-seen timestamps, seven-day activity patterns, and user counts. Not just what is running now, but what has been running.
Deep Discovery: How Are They Configured?
Catalog-level discovery tells you what agents exist. Deep discovery tells you how they are configured.
Claude Code has four configuration scopes: managed (pushed by IT), user (personal settings), project (per-repo), and local (machine-specific overrides). Each scope can contain different config objects. Higher scopes can override lower ones, or be overridden in turn. Ceros parses all four and discovers everything declared in them.
That means MCP servers, the tools agents can reach such as GitHub, Slack, databases, and internal APIs, along with which are sanctioned and which appeared without approval. It means hooks, the shell commands or webhooks that fire on agent events, where a hook that calls an external endpoint on every tool call is a meaningfully different risk than one that formats logs. It means skills and subagents, permission and sandbox rules, environment variables, model preferences, and the prompt injection surfaces like memory files and imports that feed content directly into the agent's context.
A CLAUDE.md file sitting in a project directory is part of the configuration surface. Ceros sees it.
This is configuration visibility at a level that no spreadsheet audit can replicate.
Five-Dimension Session Identity
Every agent session is an identity decision. Ceros builds a composite identity across five dimensions: who is running the agent at the OS level, who drives it at the organizational level from Ceros enrollment, what device it is running on verified by hardware-bound attestation, what program is executing including the binary and its dependency graph measured cryptographically, and what configuration is active for the session including config files, command-line parameters, and environment variables.
These five dimensions together establish ground truth. An agent session isn't just "Claude Code running." It's Claude Code version 1.4.2, running as jsmith@acme.com, on device DEV-3847-MBP, with these MCP servers enabled and these permissions applied.
This is how discovery answers not just what is running, but running as whom, on what, with what config.
The Sanctioned-but-Unsecured Gap
Here is the scenario security teams consistently miss.
Your organization sanctions Claude Code. IT pushes a managed configuration. Developers install it. Everything looks compliant. But a developer logs in with a personal Anthropic account. Maybe they had one before the enterprise subscription rolled out. Maybe the enterprise SSO had a friction point. The reason doesn't matter much. The result is the same.
The agent is sanctioned. The session is not. Your managed configuration doesn't apply because it is tied to the enterprise identity, not the personal one. Your audit trail doesn't capture the session because it is not flowing through your proxy. Your MCP governance is irrelevant because the session has whatever MCP servers the developer's personal config declares.
Proxy-only solutions miss this entirely. They see traffic from sanctioned sessions but have no visibility into what is happening at the endpoint. An unsanctioned session with the same agent, on the same device, talking to the same LLM provider but with a personal account and zero governance is invisible to them. Agent-only solutions see the process but not the traffic. They know an agent is running but cannot tell whether it is flowing through the enterprise proxy or bypassing it entirely.
Ceros sees both. Session governance isn't a policy you configure. It is a fact that gets discovered: is this session connected to the Ceros proxy, yes or no?
MCP Discovery
MCP servers are the tool layer. They give agents access to external systems: GitHub, Slack, Jira, databases, internal APIs. Each one is a capability expansion and a governance decision that someone may or may not have made deliberately.
Ceros parses config files across all four scopes to discover every declared MCP server. But declared isn't the whole story. An MCP server can appear in config the admin never sanctioned, added by a developer in their user or local scope. Worse, it can appear at runtime without being in any config file at all. If another proxy sits in the request path, or if the LLM provider injects objects into the conversation, those show up in the session but nowhere in the configuration.
For sanctioned sessions, Ceros compares declared config against runtime-observed objects. The delta is itself a discovery signal. Objects present at runtime but absent from config were injected by something upstream.
Each MCP server gets a governance state: sanctioned, unsanctioned, or inactive.
From Visibility to Control
Discovery is the prerequisite for everything downstream.
Without it, you cannot build an allowlist because you don't know what to allow. You cannot set posture requirements because you don't know what's connecting. You cannot produce an audit trail because you don't know what to watch.
With discovery in place, governance becomes tractable. You can allowlist specific agents and block the rest, require device posture checks before sanctioned sessions can start, flag unsanctioned sessions for investigation, alert on configuration changes like new MCP servers or new hooks appearing, and build behavioral baselines from the event stream that make anomalies visible when sessions deviate from normal patterns.
Because Ceros combines endpoint presence with proxy visibility, it sees the full picture. Not just what's installed, not just what's passing through a gateway, but both.
Get started with Ceros today at agent.beyondidentity.com.
Ceros is built by Beyond Identity. SOC 2 Type 2 compliant. FedRAMP Moderate ready. Deployable as cloud SaaS, self-hosted, or fully air-gapped on-premises.