Your APIs are already being called by agents
Nobody decided to expose them. An MCP server set up in an afternoon, a developer’s token, and the traffic arrives under a human identity. How to recognise it in your logs, and what to do next.
A developer on your team works with a code assistant. To spare themselves some copy pasting, they set up an MCP server in front of the internal incident tracking API. One hour of work, one environment variable, their own token inside. It works, and they told no one, because there was nothing to tell.
In your logs, nothing looks unusual either. A valid token, a known consumer, well formed calls. Except it is no longer them calling.
Nobody disobeyed
This is the same mechanism as ghost APIs and bypassing the platform. A rogue integration is never born of bad intent. It is born of a deadline, an available tool, and the absence of a faster official path.
What the agent case adds is inherited rights. The MCP server carries the credentials of the person who set it up. Not a service account, not a chosen subset. Whatever that person can do, the agent can do.
And what they can do almost always exceeds what the agent needs. A developer carries broad read access, inherited from an on call rotation or a migration. It was dormant. An agent loop does not let it stay dormant.
Why it stays invisible
Three reasons, and none is a flaw in your tooling.
The server listens locally, on a high port, inside the developer’s own tool. No asset inventory sees it, because it does not resemble anything those inventories look for.
The call that reaches you, though, is perfectly legitimate. Same token, same outbound address, same HTTP client. The gateway does not see an agent, it sees an authorised consumer.
And the control framework does not ask the right question. An API security review asks who is calling and with what proof. It does not yet ask whether a model is deciding the sequence of calls.
On servers exposed online, measurements now exist. A 2026 study validated 7,973 reachable MCP servers, of which 40.55% serve their tools with no authentication at all. Among the servers actually tested with OAuth, every single one carried at least one flaw.
What this changes in your logs
You will not detect an agent by its header. Some clients announce themselves, most do not, and nothing forces anyone to. Detection works on the shape of the traffic, and it is easier than you might think, because an agent does not look like a human hand.
The burst. Dozens of calls within seconds, then nothing for ten minutes. A screen produces one call per gesture, spaced roughly at regular intervals.
The sequence. A broad read, then a targeted read a few calls later. The agent lists before choosing, and it lists far more often than a compiled client that already knows its path.
Errors of shape. An abnormal rate of 4xx errors on parameters, with plausible but wrong values. A compiled client gets it wrong once, at deployment. A model gets it wrong differently, and on every task.
The schedule. Traffic follows a person’s working session, not their team’s office hours. And it keeps going while they have lunch.
The same token, two regimes. An identity that produces both screen traffic and burst traffic is the most reliable signal of all. It is not the same hand.
One last signal, more expensive to obtain and harder to ignore: the cost per task. When what sits downstream is a model, the bill often arrives before the audit report.
Banning it does not work
The reflex is to ban it, and it costs twice. It does not remove the usage, it moves it out of sight, onto a personal machine or into a tool nobody logs. And it destroys the one moment when that usage was still observable.
This class of incident comes from people inside the company doing their job. What pushes it back is a faster official path than the workaround. Not a memo.
Four weeks, in this order
- Measure. Run ninety days of gateway logs against the five signals above. The result is a list of human identities producing agent traffic, and it is never empty.
- Name. Give this traffic an identity that is not a human’s. As long as an agent borrows a person’s token, no authorisation decision and no audit can stand.
- Open a path. Three read only APIs, well described, exposed by the platform. That is the subject of exposing your APIs to agents, and the mechanics live in the agentic layer.
- Close. Only afterwards. Closing before opening closes nothing, it just relocates the problem.
The honest counterweight
Not everyone is affected, and not to the same degree. This year’s published agentic traffic figures are dominated by training crawlers, which have nothing to do with this topic. One network operator even observes a decline in agent traffic across nearly every vertical since late 2025.
What holds true everywhere, though, is the gap between real usage and inventory. The question is not whether agents will arrive. It is how many are already inside your organisation, and nobody knows without looking.
Published in August 2026.
On the same subject