The Control Plane Is Necessary. The Inspection Plane Is What's Missing.

There is a particular kind of engineering writing that is worth more than any vendor whitepaper: the practitioner who has actually shipped the thing, writing down the decisions they made and — crucially — the ones they deferred. A recent InfoQ case study on building a secure Model Context Protocol server on AWS is exactly that. It is careful, pragmatic, and quietly honest about its own edges. It is also, read closely, a map of a security layer that does not yet exist as a category.

The author's own framing is the right place to start. MCP is valuable precisely because it makes connecting language-model clients to real systems easy — and that ease is exactly why a production team has to treat the server as a first-class interface rather than a weekend integration. That is correct. The interesting question is what "treating it carefully" actually means once you try to do it.

In the InfoQ piece, careful means a specific and coherent set of things: narrow tool contracts, a clean separation between read and write operations, mutations disabled by default behind an explicit flag, OIDC bearer tokens carried through to the backend, tests written against mocks and then validated against the real service, and explicit rate limits on the conversational tools. Every one of those decisions is sound. Together they describe a vocabulary the industry has largely converged on in 2026. Call it the control plane: routing, identity, authorisation posture, structured logging, request shaping.

But notice where the article stops. The author is candid that the mutation flag is not a full authorisation model — it is a binary global switch, not per-caller policy. And the author names the real frontier directly: per-request telemetry is the natural next step, and it does not exist yet. That admission is the whole point of this post. The control-plane vocabulary is mature. The vocabulary for what runs through that telemetry — what you actually inspect, and what you do when the inspection finds something — has not been written down. That second vocabulary is the inspection plane, and it is the missing half of the same architecture.

Governance routes the traffic. Inspection reads it — in both directions, on the same connection.

What a careful MCP server looks like in 2026

It is worth walking through the control-plane decisions, because each one is genuinely good engineering and each one quietly hands a problem to a layer that sits behind it.

Narrow tool contracts and read/write separation. The author exposes a deliberately small surface and keeps mutating operations apart from read operations. This is the single highest-leverage decision in MCP server design. It shrinks the attack surface and makes reasoning about blast radius tractable. What it does not do is say anything about the content travelling across that narrow surface. A tool can have a perfectly minimal contract and still carry a malicious instruction inside a perfectly valid string argument.

Default-deny mutations behind a flag. Mutations are off unless an operator turns them on. This is the correct default, and the author is the first to point out its limit: it is a switch, not an authorisation model. It cannot express "this caller may mutate these resources but not those." Default-deny is a posture; it is not policy, and it is not detection.

OIDC bearer tokens to the backend. Identity is propagated cleanly from the MCP client through to the data service. This answers who is calling. It does not answer what the call is trying to do to the agent, which is a different question with a different owner. An authenticated request can still carry an injected instruction; a valid token says nothing about the intent of the payload it accompanies.

Mock-then-real validation, including MCP Inspector. The server is tested against mocks and then checked against the live backend with the standard MCP Inspector tooling. This is exactly right for development. It is worth being precise about what it is, though: MCP Inspector is a development and debugging tool. It validates that the server behaves as designed against known inputs. It is not a runtime threat inspector watching production traffic, and the article does not claim it is. Development-time inspection and runtime inspection are different disciplines; conflating them is one of the easier mistakes to make in this space.

Per-tool rate limits. The conversational tools carry explicit ceilings. Rate limiting is a real control — it bounds abuse volume and protects the backend. But a rate limit treats each call as an isolated event. It has no concept of a sequence: search, then a batch fetch, then an outbound action is a coherent chain whether or not any single step trips a per-tool ceiling.

None of this is criticism. This is one of the better practitioner write-ups on production MCP servers this year, and the engineering is correct. The point is structural: a server built this carefully still leaves four distinct questions unanswered, and all four live on the same side of the API boundary — the side the article respectfully does not cross.

The vocabulary asymmetry

Here is the asymmetry stated plainly. Production MCP servers in 2026 have a shared, mature language for the control plane: default-deny, narrow contracts, OIDC, structured logs, mock-then-real validation. They do not yet have a shared language for the inspection plane: per-tool-call threat inspection, response sanitisation, cross-tool behavioural correlation, and audit-grade evidence.

This is not because practitioners are careless. It is because the inspection plane is a genuinely harder, category-level problem, and the MCP specification's own security guidance — sandboxing, restricted transports, OAuth, audit logs — describes the control plane without standardising per-tool-call inspection semantics. The vocabulary gap is visible across the wider landscape too: several independent observability and runtime vendors have spent early 2026 describing the same missing layer from their own angles. What has been missing is a practitioner-side statement of the gap. The InfoQ piece is that statement, almost in passing, when it names per-request telemetry as the step that comes next.

So let us take the author at their word and ask: once you have the telemetry, what runs through it?

Each mature control-plane control hands an unanswered question to the inspection plane.

Where the inspection plane begins

The inspection plane is best understood as the set of questions that begin exactly where each control-plane decision ends.

A rate-limited natural-language argument is still an unfiltered injection surface. The conversational tools accept free text. A ceiling on how often they can be called says nothing about what is in each call. The inspection-plane answer is a detection layer that reads the argument before it reaches the backend — starting with deterministic pattern matching for known injection and obfuscation techniques, then escalating to semantic and model-based classification for the novel and the disguised. This is the layer that turns "we limited the tool" into "we examined what the tool was asked to do."

Flattening a response reshapes it; it does not sanitise it. The InfoQ server transforms backend results into a tidy shape for the model to consume. Reshaping is not the same as inspecting. A flattened, well-formed response can still carry an injected instruction, an exfiltration URL, or content engineered to steer the agent's next action. The inspection-plane answer is response-side inspection: examining what the agent actually receives back, not just what it sent — the direction of travel that almost nobody is watching, and the one where a compromised or manipulated upstream does its work.

Per-tool rate limits cannot see a chain. A search call, a batch fetch, and an outbound discovery call are three rate-limited events to the control plane and one coherent behaviour to an attacker. The inspection-plane answer is cross-tool behavioural correlation: a layer that holds context across calls and recognises the sequence as a sequence. This is the difference between counting events and understanding intent.

Telemetry an auditor cannot trust is not evidence. The author names per-request telemetry as the next step, and they are right. But the version that matters for a regulated enterprise is not a log file — it is a tamper-evident record an auditor can rely on. Per-request telemetry that could have been edited after the fact answers an engineering question, not a compliance one. The inspection-plane answer is an audit chain whose integrity can be demonstrated, which is precisely the kind of evidence the EU AI Act's record-keeping expectations point toward — obligations the Digital Omnibus has deferred to 2 December 2027 for stand-alone high-risk (Annex III) systems, but that are coming nonetheless.

All four of these sit past the API boundary the article respects, and none of them contradicts a single decision it makes. The relationship is not alternative; it is next layer. This is the layer the industry has begun to name — Agent Detection & Response (ADR): runtime detection and enforcement on what agents and their tools actually do, at the place identity and authorisation tools cannot see. It is the layer CheckedAgent is built for: an inline, MCP-native ADR proxy that sits on the wire between an agent and the MCP servers it calls and classifies every JSON-RPC message ALLOW, QUARANTINE, or BLOCK in real time — in both directions, on the same connection. Where the control plane routes and governs, the inspection plane reads.

Why this isn't the operator's job alone

There is a reason the inspection plane has not simply been absorbed into careful server engineering, and it is not effort. It is architecture.

The author built one server, server-side, for one platform's clients. Even done perfectly, a server operator cannot ship an inspection layer to every client that connects, across every other MCP server those clients also talk to. Inspection that only covers your own server is partial by construction, because the agent's risk is the sum of everything it touches. The inspection plane has to live where the agent's traffic converges — on the client side of the conversation, as infrastructure the agent runs behind rather than code each individual server author re-implements.

That is the honest reason this is a category and not a checklist item. The control plane can be owned by each server, because each server controls its own surface. The inspection plane cannot, because no single server sees the whole agent. It has to be added deliberately, as its own layer, by whoever is accountable for the agent as a whole.

The question to take into your next architecture review

If you run an AI platform, the useful takeaway from the InfoQ piece is not a verdict on one server. It is a distinction you can carry into the next design review: we have the control plane; do we have the inspection plane?

That reframes a conversation that usually stalls. "We need more security on MCP" invites the entirely reasonable reply, "we already have OIDC and rate limits." "We have the control plane and we don't have the inspection plane" is harder to wave away, because it names a specific, missing capability rather than a vague anxiety. For a security leader, the procurement version of the same question is sharper still: when a threat arrives inside a tool response rather than a tool call, what sees it — and where is the evidence that it did?

The honest reading of an honest article is this. A production MCP server in 2026 can be built carefully, and the InfoQ case study shows what careful looks like. Careful, today, means a mature control plane. The inspection plane — reading the arguments, sanitising the responses, correlating the chain, and recording all of it in evidence an auditor can trust — is the other half of the same architecture, and it is the half still waiting to be named and added on purpose.

CheckedAgent is an Agent Detection & Response (ADR) platform for MCP: an inline proxy that inspects JSON-RPC traffic between AI agents and their tools in both directions, classifying every message ALLOW / QUARANTINE / BLOCK in real time. It complements managed gateways and identity providers; it does not replace them.