A tool-call log is only useful if someone reads it, and nobody reads ten thousand lines of JSON a day. The promise of “anomaly detection” on an MCP gateway is that the system reads it for you and raises a hand when something looks wrong. The hard part is defining wrong. AI agents are erratic by nature; a detector tuned for a human’s habits will page you every afternoon.
This post lists the signals that have actually meant something in MCP traffic, the ones that only sound useful, and how to get value without a machine-learning project.
What makes AI tool traffic different
Three properties of agent traffic break the usual security-monitoring assumptions.
- Burstiness is normal. An agent asked to “update every open ticket” will make two hundred calls in a minute, then nothing for an hour. Rate-based alerts fire constantly.
- Tool choice is noisy. The same request can produce different tool sequences on different runs. “Never called this tool before” is weak evidence on its own.
- The attacker doesn’t log in. In most MCP incidents the compromised party is the model’s judgement, not a credential. The calls come from a legitimate user, legitimate client, legitimate token. Identity-based detection sees nothing.
So the useful signals are about what was called with what, in what order, rather than how often or by whom.
Signals that mean something
Read-then-send across servers. A call to a tool that returns personal or confidential data, followed within the same session by a call to a tool that sends content to a destination the model chose. This is the exfiltration shape described in the exfiltration post, and it is worth an alert every time it crosses a server boundary.
Secrets in arguments. A tool argument containing something that looks like an API key, a private key header, a bearer token or a connection string. Legitimate workflows almost never pass these through the model. Injected instructions almost always try to.
Out-of-scope destinations. A URL argument pointing at a domain not on the list of places this workspace has ever sent anything. First contact with a new external host is the single most reliable indicator in the fetch-and-post family.
Tool definitions changed. Not a traffic signal, but the one that precedes most others. A server whose tool descriptions differ from the approved snapshot has drifted, and every call to it after that point is suspect until someone re-approves.
Destructive tools in a burst. Ten deletes in a minute from one client is either an intended bulk action or a very bad afternoon. Either way a human should know within the minute, not in the daily digest.
Blocked-call clusters. A run of calls denied by policy from one session. That is a model repeatedly trying something it isn’t allowed to do, which usually means an instruction it picked up from content is driving it.
Signals that only sound useful
- Off-hours activity. Scheduled agents run at night. Humans in other time zones run at night.
- Call volume above baseline. See burstiness above. Useful as a cost signal, weak as a security one.
- New tool for this user. Weak alone. Useful combined with “and it’s a write tool” or “and it’s on a server they connected today”.
- Token count anomalies. Interesting for budgeting. Almost never the first sign of an incident.
Why rules beat models here
The high-value signals above are all expressible as rules over a well-structured log: session, user, client, server, tool, arguments, outcome, timestamp. You don’t need a model to notice that a send followed a get across servers, or that an argument matched a key pattern. What you need is the log to exist, centrally, with arguments included, and a classification of each tool as read, write, destructive or outbound.
That classification is the thing most teams don’t have. Tool annotations are supposed to supply it and almost no server sets them, so it has to be inferred from descriptions and names at scan time and stored alongside the policy.
Prevention first, detection second
Every signal above is cheaper to prevent than to detect. Read-then-send is impossible when the send tool is blocked for that client. Secrets in arguments don’t matter when the tool that would carry them is behind approval. Destructive bursts can’t happen when destructive tools ask first.
The right mental model is that per-tool allow, ask, or block rules handle the cases you can foresee, and detection covers the residue: the allowed read tool that turns out to return more than expected, the write tool you allowed because the workflow needed it. The narrower the allowed surface, the smaller the residue, and the fewer alerts a human has to look at.
A minimal detection setup
- Route all clients through one endpoint so the log is complete. Partial logs produce confident wrong answers.
- Classify every tool as read, write, destructive or outbound at approval time.
- Block or gate outbound and destructive tools for any client that also holds sensitive reads. This removes most of the alert volume before it exists.
- Write four rules: secrets in arguments, first contact with a new external host, destructive burst, blocked-call cluster. Send them somewhere a human looks within the hour.
- Treat drift as an alert, not a log line. Re-approval is the response.
- Read the daily digest. The anomalies you can’t write a rule for are the ones a person notices in two minutes of reading.
Anomaly detection for AI agents is less about clever models and more about a complete, classified log and a short list of rules that encode what “wrong” means for your organisation. Get the log and the classification, and the rules are an afternoon.