Find what API scanners miss.
Kernel-level sensors and traffic analysis surface the AI agents, MCP servers, and LLM API calls that never made it into any registry, and tie each connection to the host and process that opened it.
Connections seen by sensors and in traffic
09:12:03–09:12:21
5 of 6 flows reach something no API inventory lists.
- Not in any API inventory:
shadow-summarizer
eng-ws-14pid 4411
to 172.31.72.9:8080
HTTP/1.1
MCP handshake
- Host
- eng-ws-14pid 4411
- Seen by
- Sensor and traffic
- Matched on
- initialize
- Resolves to
- mcp-postgres-prod
- Owner
- No owner
- Trust
- Flagged
On Acme Corp's map, shadow-summarizer connects to mcp-postgres-prod: traffic analysis finds the connection, and the kernel sensor on eng-ws-14 ties it to the process. support-triage-agent connects to mcp-jira, the one pair an API inventory lists.
Sensors tie each connection to a process
The Octic sensor runs on servers and engineer laptops. It sees the AI apps, packages, dependencies, and processes on each host, and the network connections they make, so a connection to an MCP server arrives with the process and host that opened it.
Linux and Windows are supported today. Coverage grows as you roll sensors out.
- The sensor on eng-ws-14, a Linux workstation, sees Claude Code and shadow-summarizer running on it. The sensor on WIN-ENG-07, a Windows workstation, sees Codex.
- Claude Code, process 3982 on eng-ws-14, connects to api.anthropic.com:443.
- shadow-summarizer, process 4411 on eng-ws-14, connects to 172.31.72.9:8080.
- Codex, process 7316 on WIN-ENG-07, connects to api.openai.com:443.
- shadow-summarizer is a flagged AI agent with no owner; the address it reaches is mcp-postgres-prod.
Traffic analysis names what each connection is
Octic inspects traffic for AI-specific patterns, such as calls to LLM APIs and the handshake that opens an MCP session, and ties each one to the service that made it.
An MCP server someone stood up without telling anyone shows up the first time an AI agent connects to it.
- invoice-extractor, an unreviewed AI agent, is seen in network traffic from 172.31.40.18.
- Its connection to api.openai.com:443 matches an LLM API call: it calls the OpenAI API.
- Its connection to 172.31.40.31:8931 matches an MCP handshake (the initialize call), which puts mcp-filesystem, an unreviewed MCP server, on the map.
Anything missing from the inventory stands out
Sensor and network findings are matched against what API-based discovery reports. What the inventory lists and what actually runs land in one graph.
An AI agent with no registry entry, or an MCP server nobody registered, stands out the moment it appears, along with every API it calls.
- Anthropic API, Model API. Approved.
- OpenAI API, Model API. Approved.
- support-triage-agent, AI Agent. Approved.
- mcp-jira, MCP Server. Approved.
- Claude Code, Software Application. Approved.
- Codex, Software Application. Flagged.
- invoice-extractor, AI Agent. Unreviewed.
- shadow-summarizer, AI Agent. Flagged.
- mcp-filesystem, MCP Server. Unreviewed.
- mcp-postgres-prod, MCP Server. Flagged.
- support-triage-agent connects to mcp-jira.
- Claude Code calls Anthropic API.
- Codex calls OpenAI API.
- invoice-extractor calls OpenAI API.
- invoice-extractor connects to mcp-filesystem.
- shadow-summarizer connects to mcp-postgres-prod.
The API inventory lists 4 of these 10. Sensors and traffic found the rest: 2 coding agents, 2 AI agents, and 2 MCP servers.
Where this sits in Discover
Integrations list what your platforms’ APIs know about. Network and kernel-level discovery finds what they don’t. The graph explorer is where both land.
Back to DiscoverSee what your inventory misses
Install a sensor on a Linux or Windows host and its AI processes and connections start landing on the map. Connect your APIs, and anything they don’t list stands out.