Table of Contents
Your AI inventory lists what was declared. The agents and MCP servers running in your clusters show up only in what they do.
The pentest of your production Kubernetes cluster wraps up. The report has one finding in red.
From a foothold in a single pod, the testers reached an MCP server – a small service that hands AI agents tools to call. Nobody had listed it. It answered without asking who was calling. One of its tools ran database queries. Its database credential was production’s.
At the readout, the first question is obvious. What else is out there like it – and who is calling it?
Nobody in the room can say. The AI inventory doesn’t have it. Servers like this rarely get registered. The testers found this one because they walked in.
One server is a finding. Not knowing how many there are is the risk.
Each of them holds whatever credential its team gave it. Each is called by agents that aren’t listed either. And nothing gets cleaned up, because a cleanup needs a list, and there isn’t one.
Agents became ordinary services
Agents used to live in a vendor’s console, or on a developer’s laptop. Now teams ship them the way they ship everything else: as a container in a Deployment, with credentials attached.
That part is old. A service holding credentials is a problem security teams already know.
The new part is that the service chooses its own actions. An agent decides which tool to call, and what to send it.
And tools are easy to add. A team stands up a small MCP server, or adds one more tool to one it already runs. Any agent that can reach the server can then use it.
The wiring is configuration, not deployment. Pointing an agent at a new server is a settings change. Which tools a server offers is whatever it lists when asked. When a server gains a tool, the agent needs no change at all. It finds the new tool the next time it asks.
Every list you have is a list of declarations
- Agent platform consoles list the agents built on them. They are complete for what they host, and blind to a pod.
- MCP registries list the servers someone registered. A shadow server is, by definition, not there. OWASP gives it its own entry in the MCP Top 10: MCP09, Shadow MCP Servers.
- Code and image scanners find an agent framework in sixty images. They read repositories and registries, so they cannot say whether an image is deployed, or where. Nor what it calls, or with which credentials.
- A network scan finds servers that answer. It cannot say which agents use them.
None of them answers what is running.
Where agents run inside a platform, the platform’s own list is the right source. The gap is the agents and servers you run yourself. What is missing there is observation.
Define an agent by what it does
A workload that speaks MCP and authenticates to a model provider is an agent. It does not need to register. Its traffic says so.
An MCP server is whatever agents call. If it runs in your cluster, it is a workload too, with an image, a service account and credentials of its own.
Both can be observed where they run. Watch what each workload calls, and what it authenticates with, and the pieces connect: the agent, the servers it calls, and the tools it uses.
Which ones matter comes down to what each agent and MCP server can reach. What do its credentials open, and are they long-lived? Does it run in production? Do its calls travel in the clear?
How Hush sees it
The Hush sensor already runs across your clusters, watching how secrets are used. It observes at the operating system level. Applications are not modified, nothing needs an SDK, and no traffic routes through it.
It reads agent traffic too. MCP, and A2A for agent-to-agent calls, are decoded the same way as HTTP or Postgres, including over TLS.
From that traffic, the Hush platform builds the inventory the readout asked for:
- Agents: workloads that speak MCP or A2A and authenticate to a known model provider.
- MCP servers: every host an agent calls. In-cluster servers resolve to the workload behind them.
- Tools: what each server advertises, and what each agent actually calls.
- Credentials: everything each agent and server authenticated with, traced to its source – the vault entry, the service account, the role.
- Risk: each agent carries the risk of its credentials: what they can access and how much that matters, whether they belong to production, how long-lived they are, and whether they travel in the clear.
Take the server the testers found. The platform shows every agent calling it, the query tool it offered, and the production credential it held. And every other server like it.
One agent, as the sensor sees it: the model it calls, the MCP servers it uses, and for the in-cluster one, the credential and database behind it.
What changes
- Inventory. Agents and MCP servers are found by behavior, not by registration.
- Access. For each agent, the tools it calls and the credentials behind them – including what it reaches through a server.
- Exposure. MCP and model calls in plaintext or over old TLS.
- Priority. An agent that reaches a production database outranks one that reaches a test queue.
- New reach. A server that adds a tool, or an agent that starts calling a new server, shows up from its first call.
The testers found one server because they walked in. The rest should show up in your inventory, not in the next pentest report.