The API you gave an agent, and forgot

MCP turned every internal service into something an assistant can call on its own. The token is broad, the audit trail is thin, and the thing deciding when to call it is a model reading text it did not write.

The problem

An MCP server is an integration with a credential attached. Someone adds it to a config file in a minute, it holds a token scoped to whatever was convenient at the time, and from then on a model decides when to use it.

The trust boundary moved and the controls did not move with it. A tool result is untrusted input that goes straight into a model context, which is the cleanest injection path anyone has built in years: text arrives inside a result, the model reads it as instruction, and the next tool call is not yours.

The usual sources stay silent throughout. There is no user session to audit, no browser to instrument, and the traffic is a local process talking to an API over TLS, which every network control correctly reads as normal.

What we watch

1. 01

   Which servers a device reaches

   MCP servers seen per device, so a config file that quietly spread across a team becomes a fleet fact rather than a rumour in a standup.

2. 02

   Which tools were called

   The call and its result, in order, on the same timeline as the prompts around them. That ordering is what makes a run reviewable once it is over.

3. 03

   What came back

   Tool results are inspected as content in their own right, because instructions arriving inside a result are the attack rather than a side effect of it.

4. 04

   What the request carried

   Secrets and personal data heading out in a prompt are the same detection problem here as anywhere else, and the same guardrails apply on the surface where refusal is possible.

What you get

What it does not do today

• —Tool calls are monitor-only. The model emits them mid-stream, so they are recorded and alerted on, not refused. Refusal happens on the prompt surface, and isolation is the blunt instrument for everything else.
• —Coverage follows the deep-capture set: Claude Code over OTLP and Anthropic endpoints today, growing vendor by vendor.
• —Detection for injected instructions is heuristic and young. Monitor mode first, promote once you know the false positive rate on your own traffic.
• —We do not scan an MCP server or its supply chain. This is what your agents did with it, not what it is made of.

Frequently asked questions

Can you block a dangerous tool call?

Not on this path, and be sceptical of anyone who says they do it from the endpoint. The model emits the call mid-stream, so it is recorded and alerted on rather than refused. What can be refused is the outbound request on the prompt surface, and what can be stopped wholesale is the device, by isolating it.

Is this an MCP gateway?

No. A gateway sits in the path and can refuse a call; the sensor sits on the device and sees what actually happened, including servers no gateway was ever pointed at. A hosted gateway is in development, and the two are complementary rather than alternatives.

What about a server running locally?

A server on the same machine that never opens a network connection is invisible to a network-layer sensor. The calls to it still appear wherever the agent reports its own telemetry, which for Claude Code is the OTLP path.

Which MCP servers are risky?

The question we can answer is which ones your agents actually reach and what those returned. Rating servers in the abstract is a different product, and a catalog of ratings nobody checks against real usage is a list rather than a control.

Keep reading

• Agent oversight The runs those servers get called from.
• Tool call and tool result The two halves, and which of them is untrusted input.
• Prompt injection, defined Why a result that contains instructions is the whole problem.