The protection layer

One script, wire-protection.sh, turns the "before" demo into the "after" demo. It creates everything below and nothing else; deleting it puts the suite back exactly as it was.

# in config.sh
export DEPLOY_PROTECTION="true"    # ./deploy.sh then wires the protection layer too
export PROTECTION_MODE="block"     # or "log" to detect without blocking

./wire-protection.sh               # apply (safe to re-run)
./wire-protection.sh --remove      # tear it back down for a clean "before" run

1. DLP profiles

Five custom profiles, shared by AI Gateway and Secure Web Gateway, written specifically against the data in these apps so the matches on stage are unambiguous:

Where Cloudflare already maintains a detection, these profiles borrow it rather than re-implementing it: US and UK national identifiers, US mailing addresses, ABA routing numbers and US phone numbers are Cloudflare's own predefined entries, referenced by name and resolved at deploy time. The custom regexes are only for what is specific to this company - UK residential addresses, the field names in these apps' JSON, and the vocabulary of its HR case files.

2. AI Gateway policies

The gateway itself is not created here — wire-access.sh creates it and publishes it on its own Access-protected custom domain, because that is identity plumbing rather than inspection. Clients are therefore configured against the same endpoint whether or not this layer is deployed. What this adds to it:

• DLP policies referencing all four profiles, checking both the request and the response — so it catches a user asking for an address and a model returning one it picked up from a tool result.
• Guardrails covering two different jobs. Prompt injection blocks on prompts, which is what stops the injected email and calendar invite from steering the agent. Violent crimes, non-violent crimes, indiscriminate weapons and suicide & self-harm block on both prompt and response, governing what staff can make the company's AI do at all. Privacy is left on flag rather than block: these apps discuss people all day, so blocking it would break ordinary use, and DLP already covers the actual identifiers.
  The dashboard and the logs label these by code — prompt injection is P1, the four blocked categories are S1, S2, S9 and S11, privacy is S7 — so that is what you will see on screen.
• Logging on, so every one of the demos leaves an entry you can open on stage.

3. MCP server portal

The five MCP servers are registered with Cloudflare Access and published through a single portal at :

• Users authenticate to the portal through Access, then to each upstream server as themselves (on_behalf), so Alice's own permissions still apply upstream.
• Access policies control which servers each person even sees in the portal. Four allow the All Employees policy; allows only Executives, which is why Ledger's tools are absent from an ordinary employee's tool list rather than merely refused. See the access-control script.
• Route traffic through Cloudflare Gateway is turned on, which is what makes the next section possible. The portal terminates the client connection and re-originates it, so Gateway can decrypt and inspect the tool traffic without any account-wide TLS decryption setting.
• Every tool call is logged in Access, independently of Gateway.

4. Application Library review statuses

Cloudflare keeps a catalogue of SaaS applications, and every one of them carries a review status for your account: Unreviewed, In review, Approved or Unapproved. This layer sets them, because it is what lets the two AI policies below decide anything without naming a single hostname.

Gemini is deliberately In review rather than Approved. It has to not match the redirect rule, since it is where that rule sends people, and "in review" is the honest description of a tool a company is still making its mind up about — which is where most of the audience actually is.

5. Gateway HTTP policies

First, TLS decryption is turned on. Without it an HTTP policy only ever sees port 80, and everything these rules read — the URL, the headers, the body DLP inspects — is inside the TLS session. The policies look perfectly healthy while inspecting nothing, and the dashboard says so in a banner above the policy list.

Then one DLP policy per upstream MCP hostname. Gateway policies for portal traffic have to match the upstream server, not the portal, so there is a rule for each of , , , and , each pairing that host with the profiles that matter for it. In block mode a matching tool call or tool result is blocked and the agent gets an error instead of the data; in log mode it is allowed and recorded.

Two more rules have nothing to do with MCP, and both match on the Artificial Intelligence content category rather than a list of hostnames — a hostname list is a list of the services you already thought of, and the one someone pastes payroll data into next week will not be on it:

• Prevent sensitive data reaching public AI. DLP over all five profiles on anything posted to any AI service. When it blocks, the Cloudflare One client raises a desktop notification — "Blocked access to AI due to detection of sensitive data." — because the browser otherwise shows the person a failed request and no explanation.
• Redirect non approved AI. Anything in the AI category that is Unreviewed or Unapproved is redirected to Gemini instead of being refused. Lowest precedence in the account, so the DLP rule above answers first: someone pasting customer data into ChatGPT is blocked, not quietly rerouted. Nobody's work stops, so nobody goes looking for a way around it — which is the only version of a shadow-AI policy that survives contact with real users.

Where each control shows up

What it deliberately does not do

It does not change a line of application code, and it does not fix the leaky endpoints. That is the argument: the apps are still exactly as over-sharing as they were on the data page, and the control sits in the path instead of in a backlog.