MCP tool server security

The first is that the descriptor is instruction surface. A tool’s name, its description and its input schema are all fed to the model to help it decide what to call and how, which means an upstream server that quietly rewrites a description can steer an agent without anything in your code changing and without a single anomalous request. This is the rug-pull shape of supply-chain attack, and it is materially different from a compromised dependency because there is no artefact in your build to scan.

The second is that the tool result is attacker-authored text. Whatever the tool returns re-enters the model’s context, and the model does not reliably maintain the distinction between data and instruction. A tool that reads a ticket, fetches a page or queries a table is a channel from whoever wrote that content into the agent’s reasoning. Any defence that inspects only what a user typed misses this entirely, and it is where real hijacks come from.

The third is the least glamorous and the most likely to bite: registering a server is a privileged act that does not look like one. An MCP server row names a URL and an environment variable whose value gets sent as an Authorization header to that URL. In Token Observe that row is writable at operator rank rather than admin, and the outbound call is triggered by any viewer listing that server’s tools. Unguarded, that primitive reads any variable in the process — the session secret, the audit key, cloud credentials, every provider key — and posts it anywhere on the internet. It is the most powerful thing in the whole tool subsystem and it is shaped like a configuration form.

Two further properties of the protocol shape the design. Tool calls are proposed by a model rather than by a programmer, so the argument values are as attacker-influenceable as the prompt. And the catalogue is dynamic: servers can add, remove and change tools between requests, so anything cached has to be re-verified rather than trusted for the life of a process.

Return the tool list filtered to what the calling agent may actually use. That stops a framework picking a tool off the catalogue that will be refused three lines later, and it is the point where the permission model becomes visible to a client that knows nothing about your governance layer.

Then re-enforce the grant when the tool is called, independently, because a client can simply guess a name or remember a stale catalogue. Treating list filtering as access control is a known anti-pattern and it is easy to fall into, because in ordinary operation the filtered list and the enforced grant agree — right up until the moment somebody is probing.

Distinguish the two refusal shapes, because they carry different information and leaking the wrong one is free reconnaissance. A tool the agent cannot see should come back as an unknown-tool protocol error rather than as forbidden: telling an agent which tools exist but are off-limits is a map of your estate. A tool the agent can see but may not use right now — blocked by policy, awaiting an approval, over a rate limit — should come back as an error result the model can read and act on, carrying a machine-readable code beside the human-readable text so a well-behaved agent can react rather than retry blindly.

Record the refusal either way. A denied tool call should open a trace, record the denial with a note of whether the tool actually existed, and close as blocked. An agent working through tool names it was never granted is exactly the pattern an investigation needs to see afterwards, and it is invisible if refusals are dropped on the floor.

The same intersection rules that govern model calls apply here. Where a request names upstream agents, every hop must allow the tool call independently; an unresolvable hop should contribute an empty role set and deny through the ordinary intersection rather than being silently skipped, and the chain should be bounded — Token Observe truncates at eight hops on the tool path.

Everything crossing this boundary is untrusted in both directions: arguments are proposed by a model that reads attacker-influenced text, and results are written by systems you may not control. Both need the same treatment as a prompt — normalise the text, then scan it for sensitive data and for injection — and both need bounds, because inspection is inline work on attacker-controlled input.

The bounds have to be explicit, and exceeding one has to fail closed rather than truncating. Token Observe inspects descriptor descriptions, schemas, argument trees and result trees across both JSON keys and values under a hard depth of 32, a node limit of 5,000, a per-string limit of 65,536 characters and an aggregate detector-input limit of the same, and exceeding any bound refuses rather than forwarding an uninspected tail. That last clause is the important one: a deeply nested payload that silently skips the part you did not walk is a hole shaped exactly like the thing an attacker would build.

Withhold a descriptor that itself contains injection or secrets rather than presenting it with a warning, because the model is the thing that will read it. And withhold content types you cannot inspect. Token Observe passes through text blocks and structured JSON, and withholds image, audio, blob and resource content after the tool returns, because it has no bounded media decoding or optical character recognition — which means a picture of a prompt is a channel it cannot read.

That refusal has an unusual property worth designing for, and it is the honest bit. The tool has already run. A withheld result is not a prevented action; it is a completed action whose output is not being shown. So the refusal has to be terminal and it has to say so explicitly, because an agent that reads a refusal as retryable will run the side effect again. Anything that returns a soft error where the effect already committed is manufacturing duplicate refunds.

The same reasoning is why a tool call worth gating deserves more than a policy check. Where an action is irreversible, the useful construct is a bounded contract around the call — a declared expectation of what committing looks like, verified externally afterwards, with a defined compensation or manual-review path when verification fails. Token Observe’s effect contracts are deliberately not an expression language: they select JSON values, compare them with six bounded operators and copy them into pinned tool arguments, and they cannot run code or interpolate a template. A contract that could execute arbitrary logic would be a second injection surface sitting inside the control.