對抗性 MCP 工具呼叫實際上是甚麼樣子，以及如何在程序內篩查

The tool call is the attack surface now

Most agent security conversations are still about the prompt: jailbreaks, instruction hierarchy, guardrails on what the model says. That matters. But the moment an agent can do things — read files, query databases, call APIs, move data between systems — the interesting attack surface stops being what the model says and becomes what the model is induced to do.

An MCP tool call is a structured, machine-actionable request: a tool name, a set of arguments, and a result that flows back into the model's context. Every element can be attacked — the call directly, the tool's description before any call happens, the result carrying payloads aimed at the next call. If nothing inspects that traffic at the boundary, the first sign of trouble is the side effect: the query that already ran, the file that already left.

I build Maxion-mcp, a security gateway for exactly this boundary. This post is about the shape of the problem as I've seen it from the builder's side: the categories of adversarial tool calls I screen for, why the screening has to live in-process, and the numbers from my own testing — labeled as exactly that.

Four categories of adversarial tool calls

1. Argument smuggling

The tool's schema says one thing; the arguments say another. A parameter typed as a simple identifier carries a fragment of SQL, a shell metacharacter sequence, a path traversal, or a second, hidden instruction embedded in a free-text field. Each argument looks plausible in isolation. The payload only exists in how the receiving system interprets it — which is precisely why schema validation alone misses it. The schema was satisfied. The intent wasn't.

2. Tool-description poisoning

This one happens before any call. A tool's description is context the model trusts: it shapes when the tool gets chosen and how its arguments get filled in. A poisoned description can quietly steer behavior — instructing the model to include extra data in a parameter, to prefer a malicious endpoint, or to treat a harmful action as routine. The call that eventually fires can look completely ordinary, because the manipulation already happened upstream, in prose.

3. Confused-deputy escalation

Agents routinely hold more privilege than the conversation that drives them. A request that starts innocuous — summarize this document, look up this record — gets steered, step by step, into an action the original requester could never have performed directly: reading outside the intended scope, chaining a read tool into a write tool, escalating from lookup to modification. No single call is outrageous. The sequence is the exploit, and the agent is the deputy holding the keys.

4. Telemetry exfiltration

Agent systems generate rich operational data: prompts, tool arguments, results, traces. That telemetry is a concentrated record of everything the agent touched — which makes it a target in its own right. Exfiltration here doesn't need a dramatic breach; it can ride along inside legitimate-looking log exports, oversized result payloads returned into context, or telemetry piped somewhere it was never meant to go. If you don't treat agent telemetry as sensitive data, someone eventually will.

Why the screening has to be in-process

You could screen tool calls with a separate service, and for some architectures that's right. But screening sits on the hot path of every tool call. A network hop per call adds latency to each step of a multi-step agent loop, plus a failure domain that has to be up for the agent to work at all. Latency that's noise in a dashboard becomes a tax multiplied by every call an agent makes.

So the screening layer in Maxion — Diamonize LSA — runs in-process, as a compiled binary, with zero network hops per check. The check itself is deterministic pattern screening against known adversarial shapes: argument structures, known-bad sequences, boundary violations. That design point is also why the engines ship the way they do: compiled binaries, running 100% locally, no phone-home, and no usage telemetry collected by the gateway itself. A security component that reports back to a vendor cloud is a strange thing to bolt onto a system you're trying to keep contained.

The same local-first logic applies to the telemetry the workload produces. Quezar, the third engine, compresses structured telemetry and keeps it in authenticated encrypted storage — the data stays yours, on your infrastructure, in a form you can still use.

The numbers, such as they are

These are results from my own internal testing (October 8, 2026 test report — details in the repo). Treat them with the skepticism any vendor-run numbers deserve; the limitations section below is not boilerplate.

V16 is the throughput and thermal governor — the unglamorous piece that keeps an agent host from throttling itself into uselessness under sustained load. It's in the table because efficiency is part of the same problem: a gateway that secures the boundary but strangles the workload won't survive contact with production.

Public repo: github.com/aruuhii2yo/maxion-mcp

Honest limitations

Three, stated plainly:

Known patterns only. The 54/54 figure means 54 out of 54 patterns in a known-pattern test set. It says nothing about novel attacks, and pattern screening is inherently a defense against recognized shapes. Anyone who quotes you a block rate without that qualifier is selling you something.

This is internal testing. I designed the tests, I ran them, I sell the product. The results have not been independently audited, and you should weight them accordingly. The methodology is in the repo so the numbers can be argued with — that's the most I can honestly offer until someone else runs them.

Screening is one layer. An in-process gateway inspects tool calls at the boundary. It does not fix over-privileged tools, sloppy schemas, or a deployment that hands an agent credentials it should never have had. Least privilege still does most of the work; screening is what watches the door you actually built.

If you want your own surface mapped

I run a fixed-scope MCP Attack Surface Audit as step 1 of a 30-day Maxion pilot: I map your tool surface against these categories and hand you a written report that's yours to keep either way. The pilot is $2,500 through October 29, 2026 (regularly $10,000), with a 30-day money-back guarantee on the pilot.

If you're shipping agents against MCP tools and want to know what your boundary actually looks like: aruuhii2yo@gmail.com.

— Kyle Loiacono, Founder & Chief Technology Architect, J&K Advanced Technologies