MCP governance
MCP audit logs and rate limits
Agents retry, fan out and work without pausing, so traffic through an MCP server behaves differently from your other API clients. Limits keep a bad loop small, and a good audit log explains it afterwards.
Written by Octri · Checked 3 November 2026
What an audit log should record
The specification tells servers to rate limit tool calls and tells clients to log tool usage for audit. It leaves the format to you. For each write, these fields answer most of the questions an incident raises:
- The tool name and the API request it produced
- The arguments, with credentials and personal data removed
- The person or team the call acted for, and the client that sent it
- Whether a person approved it, declined it, or a policy allowed it
- The status that came back, and any correlation ID your API logs share
Sign-in and scope events
Tool calls are half the record. The specification also suggests logging scope elevation, meaning what was requested and what was granted. Together with grants and revocations, that shows how an agent came to hold the access it used.
Per-tool rate limits
One limit for the whole server treats a search and a refund the same. Set limits per tool, starting from what a person doing that job would plausibly need, and give expensive or sensitive tools their own lower number.
Return a limit as a tool error with isError set and a clear message. The specification notes that clients should pass tool execution errors to the model, so the agent can read the message and adjust.
Write caps
A rate limit slows a loop. A write cap ends it. Capping the writes in one run bounds how much an agent can change before a person looks, however slowly the calls arrive.
Protocol sessions no longer exist as of revision 2026-07-28, so a server on that revision needs its own definition of a run, such as a grant, a time window or a workflow handle.
Separating agent traffic
Your API’s own limits still apply behind the server. Identify MCP traffic to your API so you can see it in your metrics, and so a busy agent spends its own budget and leaves the rest of that customer’s traffic alone.
How Octri handles this
The audit log records each write an agent attempted: the tool and request, its arguments, who sent it and from which client, whether the person approved it, and the status that came back. You can export it. It is kept for 12 hours on Free, 30 days on Starter, 90 days on Growth and 365 days on Business.
Cap writes per session stops a session after a set number of calls that change data. Cap calls per minute per tool slows any single tool, with per-tool limits for those that need their own number. Both apply on every plan.
Limits are checked before the approval prompt, so an agent over its cap is told so without asking the person anything.
Signed-in people are listed with the client they used and when it last made a call, and any grant can be ended from that list.
Questions
That depends on the data. Your API’s access logs usually cover reads already, so many teams keep the MCP audit log to writes. Reads of regulated data are the common exception. Octri’s audit log records writes.
References
Checked against MCP specification revision 2026-07-28 on 3 November 2026.
Further reading
- One user, 200 API calls: rate limits when agents run in parallelFrom the Octri blog.
- Giving an agent write access to your API: what to exclude firstFrom the Octri blog.
- MCP security best practicesThe full checklist: sign-in, token checks, least privilege, approvals, limits and audit logs.
- MCP OAuth and authorizationThe sign-in flow in request order, from the first 401 to a scoped access token.
- Token passthrough and confused deputyWhat the specification forbids, why it does, and how per-client consent closes the proxy attack.
- Tool poisoning and prompt injectionHow instructions reach a model through tool metadata and results, and the controls that contain them.
Try it on your own spec
Generate an MCP server from your OpenAPI spec on the Free plan, with every tool set to run, ask first or stay off.