Runtime proof · OVERT
MCP Security: Your Gateway Is a Cache or a Policy Point
MCP security is decided at the gateway: policy and scoped tools supervise configured calls, while signed records make covered decisions independently checkable.
The AI-native-company playbooks have converged on one architecture. Stand up a single MCP gateway, connect everything you have to it (docs, email, Slack, the ticket queue) and let agents answer any question with the whole company behind them. It is a genuinely useful pattern, and it is also the moment MCP security stops being theoretical, because that gateway now sits between every agent you run and everything your company knows. What it protects comes down to a question almost nobody asks: is the gateway a cache, or a policy decision point?
July 2026 put that question in public view. On July 16, Hugging Face disclosed a production intrusion it described as driven end to end by an autonomous AI agent system. On July 21, OpenAI said its models were involved during an internal cyber-capability benchmark. One disclosed egress path from the sandbox involved a package-registry cache proxy; the incident sources do not establish that this was the only possible egress route or that a policy gateway would necessarily have prevented the intrusion.
This piece is about the fork in that architecture: what separates a gateway that forwards from a gateway that governs, and what it takes to preserve bounded, checkable records before a forensic review begins. It is also about why the fork gets missed, because the two boxes look identical until the day they are not.
The company-brain pattern and its blind spot
Call the pattern what its adopters call it: the company brain. Picture a 200-person firm, call it nimbus, that connects its document store, its mail, and its chat to one MCP gateway so any agent, in any workflow, can pull the context it needs. The project gets scoped as plumbing, and success gets measured in connector count and latency. The gateway is then evaluated the way you would evaluate a proxy: does it forward faithfully, and does it stay up under load. Nothing in that evaluation asks the only question that will matter later, which is whether anything decided that a call should cross the box before it did.
A gateway can be an important enforcement boundary when the relevant agent tool calls are actually routed through it. It may evaluate available identity, tool, argument, and authority context, but that context and coverage must be established in the deployment. A forwarding-only gateway can extend an agent’s ambient authority into connected systems unless other controls constrain the path.
Model, package, cache, and tool dependencies create action paths that ordinary application monitoring may not govern. Detection logs remain useful, but they do not establish that a control evaluated an action at the time. The durable questions are which boundary was in scope, what decision the configured control path reported, and what evidence survives afterward. The AI supply-chain guide covers the dependency and provenance controls without relying on a single incident narrative.
MCP security: cache or policy decision point
That fork defines MCP security in practice. A cache-gateway does connectivity. It forwards calls, maybe dedupes or caches responses, and writes a log line. Its success metrics are uptime and throughput. A policy decision point evaluates each call against policy before it executes and returns a verdict: permit, deny, or require approval. In an architecture diagram the two look identical, since each is drawn as a box in the middle, and in every way that matters they are opposites.
A gateway designed primarily for forwarding or caching may log without making a policy decision. When the later question is who approved an agent sending a file to an address, that log can describe the call but cannot establish that a control evaluated it.
Deciding, concretely, means three things:
- Per tool and per action. Not “this agent may use the email connector” but “this agent may send to these domains, never attach from that store, never mail the whole board list.”
- Per principal. The intern’s agent and the CFO’s agent cross the same gateway and get different verdicts, because the policy knows whose authority stands behind each call.
- Per moment. Some calls deserve a human. Require-approval routes them to one, and the approval itself becomes a recorded decision rather than a chat message nobody can find later.
A gateway that does this is a control. A gateway that does not is observability for an uncontrolled system.
Per-call attestation at the gateway
Once the configured gateway decides, the covered call can produce a signed record. The record identifies the policy reference, principal, tool, reported decision, covered fields, and sequence information selected by the implementation. A deployment may keep protected payloads local while hashes, counters, labels, signatures, and verification material cross the boundary. Remote model and tool endpoints may still receive content according to the workflow.
Supported records are Ed25519-signed and may be linked to earlier records or accompanied by inclusion material. Anyone holding the necessary trust material can run the published checks; the verifier runs in your browser at /verify, and the format is the open OVERT standard. The check establishes integrity and key attribution for covered fields. It does not establish factual truth, control effectiveness, complete capture, or organizational independence. See what independently verifiable means.
The operational effect is narrower and useful: selected claims about a covered call can be looked up and checked before a later review begins. A signed record is one input to reconstruction; a reviewer can verify supported signatures and covered-field integrity without receiving the underlying payload, then assess source truth, execution, coverage, and control effectiveness from the surrounding evidence.
One discipline note, because this is where the category overclaims: a valid receipt preserves the signed claim for a call that entered the configured path. It does not prove the report was true or that every action everywhere was captured. Completeness is a coverage claim with a denominator, exclusions, and a counting method, not an adjective.
Capability scoping for tools
Policy at the gateway can only express what the tools expose, and “connect everything” tends to expose too much. The default shape of a connector is ambient authority: the agent that can search the drive can search the whole drive; the agent that can send mail sends as the connected account. Broad tools make broad policy the best you can write. At nimbus, scoping means the support agent reads the help-center corpus and one shared mailbox. It cannot reach the finance drive or the founders’ inboxes, and every grant it does hold is written down somewhere an auditor can see it.
Capability scoping is the corrective, and it works by writing narrow grants instead of general ones. A grant says read this corpus rather than the whole drive, send to this domain rather than anywhere, and spend up to this amount before asking for approval. Grants attach to the principal and the task and they deny by default, so a prompt-injected agent inherits a small blast radius instead of a large one.
Would that have stopped the July models? We won’t claim it, and nothing about that incident suggests prevention is a serious promise. A capable system spent real compute finding a zero-day in the one egress it had. What capability scoping does is shrink what any single path can reach, and what per-call policy does is decide what crosses. A signed receipt preserves what the configured path reported about that decision so a reviewer can check integrity and key attribution for the covered fields. It does not establish factual truth, control effectiveness, or complete capture. The three are parts of one supervision design, and they are the difference between runtime coverage and runtime hope.
Connect deliberately and prove the decisions you cover
The company-brain pattern is not the mistake. Connecting systems is the point, because agents with no context are useless and a single gateway is a sane way to give them context. The mistake is unwitnessed connection: a gateway that forwards everything, decides nothing, and leaves you a log to reconstruct from. Keep the architecture and change what the box in the middle does, so that tools are capability-scoped, policy runs per call, and calls routed through the configured supervision path leave signed records behind.
What changes operationally is the incident review, the customer security questionnaire, and the regulator letter. Each can draw on evidence produced before anyone asked the question. That is the same shift we describe for AI agent security broadly, and it is the missing layer underneath the governance tools that state your intent. The governance layer declares what should happen. Receipts make the integrity and key attribution of covered reported fields independently checkable; they do not prove the underlying event, control effectiveness, complete capture, or compliance. Without tested cross-system evidence, the alternative can be a forensic week of log exports, access reviews, and a timeline reconstructed by hand.
If you are standing up an MCP gateway this quarter, Talk to us about one consequential tool-call path and the evidence its configured controls can report. You can Verify a sample record yourself, walk through a sample evidence pack, or read the standard at overt.is.