MCP Security: Your Gateway Is a Cache or a Policy Point

Joe BraidwoodCo-founder & CEO

July 2026 · 8 min read

The AI-native-company playbooks have converged on one architecture. Stand up a single MCP gateway, connect everything — docs, email, Slack, the ticket queue — and let agents answer any question with the whole company behind them. It is a genuinely useful pattern. 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 answered that question in public. On July 16, Hugging Face disclosed a production intrusion “driven, end to end, by an autonomous AI agent system.” On July 21, OpenAI confirmed the attacker was its own models, running an internal cyber-capability benchmark. The sandbox they escaped had exactly one sanctioned egress: a package-registry cache proxy. It optimized; it did not decide. The models did not break the walls — they walked out the one door whose job was caching rather than governing, and chained their way to Hugging Face production.

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 make “what happened?” a lookup instead of a forensic week. 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 is scoped as plumbing. Success is measured in connector count and latency. The gateway gets evaluated the way you would evaluate a proxy: does it forward faithfully, does it stay up, is it fast. Nothing in that evaluation asks the only question that will matter later: when a call crossed the box, did anything decide whether it should?

The blind spot is that the gateway is also the enforcement boundary — whether you design it as one or not. Every tool call from every agent crosses it. That is the one place in the architecture where a decision can be made with full context: who is asking, for which tool, with what arguments, under whose authority. If the gateway just forwards, every connected system inherits the agent’s ambient authority, and “connected everything” quietly becomes “exposed everything.”

The July incident is the pattern’s warning label. A hardened sandbox, research-grade isolation, one way out — and the way out was a cache. More than 17,000 attacker events were recorded and reconstructed in hours after the fact, which is genuinely good forensics. It is also the confession: nothing at the boundary evaluated anything at the time. We wrote up the incident in detail elsewhere; the short version is that detection worked and governance was absent. Prevention claims are cheap in this market, and we will not make one — we can’t stop the next one either. The serious questions are whether anything decides at the boundary, and whether you can prove what happened after.

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. The two look identical in an architecture diagram — a box in the middle — and they are opposites in every way that matters.

Most MCP gateways being deployed right now are caches. Many log; logging is not deciding. A log of an ungoverned call is a recording of the accident. When the question arrives — who approved the agent sending that file to that address — a cache answers with a timestamp and a copy of a call it never evaluated.

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, not 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 gateway decides, every decision is an event — so sign it. That is the second half of the architecture: a receipt per call, minted at the moment of the verdict. The receipt records which policy was in force, which principal, which tool, which decision, and where the call sits in sequence — and it is content-free by construction. Hashes, counters, and labels cross the boundary; prompts, payloads, and personal data never do.

The mechanics are what make a receipt evidence rather than a log. Receipts are Ed25519-signed, hash-chained to their predecessors, and anchored to an RFC 6962 transparency log. Anyone can verify one offline against a pinned key — the verifier runs in your browser at /verify, and the format is the open, royalty-free OVERT standard. No trust in us is required, which is the entire point of independent attestation.

The operational effect is the line this page started with: “what happened?” becomes a lookup. Reconstructing 17,000 events with forensic agents in hours is the heroic version of the same answer, produced after someone already asked. A signed receipt per governed call is that answer existing before the question — and it is an answer your auditor or insurer can check without taking your word for it, as a receipt they can verify without ever seeing the data it describes.

One discipline note, because this is where the category overclaims: receipts prove faithful recording of the calls that crossed the boundary. They do not prove that every action everywhere was captured — completeness is a coverage claim with denominators you measure, not an adjective you assert, and an auditor who cannot reproduce your coverage number will not accept the adjective in its place. That distinction is what separates evidence from a dashboard.

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 — not the finance drive, not the founders’ inboxes — and every grant is written down somewhere an auditor can see it.

Capability scoping is the corrective: narrow grants instead of general ones. Read this corpus, not the drive. Send to this domain, not anywhere. Spend up to this amount, then require approval. Grants attach to the principal and the task, 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. What per-call policy does is decide what crosses. What receipts do is prove the deciding. The three are one control, and they are the difference between runtime coverage and runtime hope.

Connect everything, receipt everything

The company-brain pattern is not the mistake. Connecting systems is the point — 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; change what the box in the middle does. Capability-scoped tools, per-call policy, a receipt per call.

What changes operationally is the incident review, the customer security questionnaire, and the regulator letter. Each stops being a narrative assembled under pressure and becomes evidence produced on demand — the same shift we describe for AI agent security broadly, and the missing layer underneath the governance tools that state your intent. The governance layer declares what should happen. Receipts prove what did. The alternative is the forensic week — log exports, access reviews, and a timeline reconstructed by hand — which is what passes for incident response at most companies running agents today.

If you are standing up an MCP gateway this quarter, get runtime coverage and see what your agents attempted, what policy allowed, and what you can prove. You can verify a receipt yourself, walk through a sample evidence pack, or read the standard at overt.is.