Securing Every AI and MCP Interaction with Cloudflare

Third in a series. Cybersecurity and Artificial Intelligence (2023) introduced the Zero Trust approach to AI; The CISO’s Guide to Securing AI (2025) mapped ten common threats to Cloudflare controls. This one organizes by who or what is interacting with AI, because each actor reaches AI over a different path, and each path has a different inspection point.

Most organizations already have an AI usage policy. Very few can tell you whether it is being followed.

That is a visibility problem, not a policy problem. An employee pasting customer data into a chatbot, a coding agent calling an LLM API from an IDE, an MCP client invoking a tool against production, and a customer-facing chatbot answering a prompt injection are four different traffic flows. They share no protocol, no identity model, and no logging surface – so a control that catches one silently misses the other three. Here are all four, the Cloudflare inspection point that governs each, and how to build agents that stay inside them.

The Four Surfaces

Which inspection point applies is decided by how the traffic arrives, so they are not interchangeable:

One dependency the diagram makes deliberately explicit: the workforce path only exists if you build an on-ramp for it. The other three do not share it – an agent reaches AI Gateway because you configured it to use that hostname, a customer reaches AI Security for Apps because your domain is proxied, and CASB needs no traffic path at all.

Getting Traffic to Cloudflare

An inspection point that never sees the traffic enforces nothing. Pick the connectivity option that matches what you need to cover:

• Device client – the Cloudflare One Client (formerly WARP) tunnels device traffic over MASQUE with post-quantum cryptography (PQC), or WireGuard. The on-ramp for laptops running browsers and IDEs.
• Proxy endpoint – Gateway policies via a PAC file, nothing installed. For contractors and unmanaged machines.
• Cloudflare Mesh – bidirectional connectivity with a private Mesh IP per node, preserving source IPs. For servers and CI runners calling AI APIs.
• Cloudflare Tunnel – outbound-only connector reaching a self-hosted model or internal MCP server without opening inbound ports.
• Cloudflare WAN – GRE and IPsec tunnels for branch offices and data centers.

Order of Enforcement

Gateway policies run in a fixed order: DNS → resolver → egress → network → HTTP. Within HTTP policies:

1. Do Not Inspect
2. Isolate
3. Allow / Block / Do Not Scan
4. Body inspection (DLP, antivirus, file sandboxing)

Evaluation is first match. Put specific AI policies above catch-alls, and remember that a Do Not Inspect rule placed high neutralizes every DLP rule below it for that traffic.

Be Honest About the Blind Spots

Inspecting HTTPS requires TLS decryption – a root CA on managed devices, decrypted in memory in Cloudflare’s data centers.

The certificate does not stop at the OS trust store, and this is the detail that derails rollouts. Much of the tooling that matters most for AI work keeps its own trust store and fails with certificate errors until you tell it about the Cloudflare CA (full guide):

Docker deserves deliberate planning: containerized build agents and CI runners are where AI tooling now lives, and a container that has never heard of your root CA fails every outbound HTTPS call the moment inspection turns on. Other traffic cannot be decrypted at all: certificate pinning (common in desktop AI clients and IDE extensions), mutual TLS, self-signed certificates, and ECH/ESNI all force a Do Not Inspect policy – and with it you lose HTTP logging, DLP, and antivirus for that traffic. This is the strongest argument for the sections that follow: when you cannot inspect an agent on the wire, point it at an endpoint you control instead – an AI Gateway hostname or an MCP Server Portal – moving governance to the application layer, where pinning is irrelevant.

Knowing How Traffic Arrived

The Traffic Source selector exposes net.onramp.type in HTTP and Network policies, so rules can depend on how traffic reached Cloudflare:

device_client    Cloudflare One Client (WARP)
mesh             Mesh connector
cloudflare_wan   Cloudflare WAN (Magic WAN)
proxy_endpoint   Proxy endpoint (PAC file)
clientless_rdp   Clientless RDP session
agentless_biso   Clientless Browser Isolation
mcp_portal       MCP Server Portal

A companion selector, net.is_isolated, identifies Remote Browser Isolation (RBI) sessions; mcp_portal is what turns MCP governance from advisory into enforceable, below. Separately, Worker egress now flows through Gateway: Workers using cf1:network VPC bindings send public traffic through Gateway with policies applied and logs written – so the agents your own team builds inherit the same policies as your employees’ laptops.

Surface 1: Workforce in Browsers and IDEs

Inspection point: Secure Web Gateway (SWG).

The goal is not to stop employees using AI, but to know what they use, decide what is acceptable, and make the acceptable path the easy one.

Discover, then classify. Shadow IT discovery surfaces the AI applications your users actually reach, and each moves through a review workflow – Unreviewed → In Review → Unapproved → Approved. That status is not cosmetic: it is both a policy selector and an analytics dimension. The AI Security report adds five panels – top AI applications by user count, application counts per review status, data uploaded by review status, MCP servers behind Access over time, and Access login events to those servers. It needs Gateway inspecting outbound traffic and MCP servers behind Access; without both it is empty, which is itself a signal.

Control what leaves. Data Loss Prevention is what makes an AI usage policy enforceable. Applied through Gateway HTTP policies with TLS decryption on, it scans request bodies – chat messages, file uploads, form submissions – before they reach a provider, in memory, never written to disk. For investigation, enable payload logging for encrypted copies, or Logpush matches to your SIEM. Where blocking is too blunt, Remote Browser Isolation is the middle path: people read and type in a tool you allow but do not fully trust, while upload, download, and copy-paste stay disabled – combinable with DLP.

The IDE problem. Some coding-agent traffic is ordinary HTTPS that Gateway inspects cleanly; some comes from clients that pin or self-sign certificates, where Do Not Inspect is the only way to keep the tool working. SWG then gives you a connection record and nothing more – you see that an agent talked to a provider, not what it said. That is a property of the transport, and the answer is Surface 2.

For the threat-by-threat treatment of the browser surface – phishing, deepfakes, social engineering, DDoS and rate limiting – see The CISO’s Guide to Securing AI.

Surface 2: Agents and MCP Clients

Inspection points: AI Gateway (model calls) and MCP Server Portal (tool calls).

An agent does two different things: it calls a model to think, and it calls tools to act. Conflating them is the most common mistake in AI governance – “sent a prompt to a provider” and “executed a write against production” are not comparable risks.

2.1 Model Calls: AI Gateway

The goal is to eliminate the shared API key. While a team shares one provider key, you cannot attribute usage, enforce per-person limits, or revoke one individual.

Start with a custom domain. AI Gateway custom domains collapse:

https://gateway.ai.cloudflare.com/v1/{account_id}/{gateway_id}/openai/v1/chat/completions

into this:

https://ai.example.com/openai/v1/chat/completions

And, more importantly, give Access something to sit in front of.

Then put Access in front of it. The Access JWT becomes the request credential, replacing the gateway token, and every request carries cf.user_id – the JWT sub claim, not the email address – so logs, analytics, and spend are filterable by authenticated user. Cloudflare-only credentials are stripped before the request is forwarded upstream. Machine-to-machine callers use service tokens, which carry no cf.user_id because they do not represent a person. One consequence to plan for: once the domain is protected, every request to it must pass an Access policy, so migrate callers before you flip it on.

Then watch what that identity reveals. The identity-aware AI Gateway flags a session costing more than 2× that user’s own 30-day p95 and landing in the account’s most expensive 1% of sessions – the second condition is what keeps it a rogue-behavior feed rather than a noisy log. Per-user budget buckets block requests or fall back to a cheaper model at the limit.

Then inspect content. AI Gateway DLP shares detection engines and account-level profiles with Cloudflare One DLP – configure a profile once, apply it in both places. It scans prompts, model responses, tool call arguments and results, and text in multipart bodies; binary data, base64 images, and external URLs are not. Two caveats: response scanning buffers the full streamed response first, increasing time-to-first-token (noticeable in a chat UI, irrelevant for batch agents), and DLP applies per gateway and uniformly, so different inspection needs mean separate gateways.

The Workers AI and AI Gateway unification then removes the split between models Cloudflare hosts and models you call – one env.AI binding, one wallet, one dashboard, with credits applying across providers. Governance-wise, one place answers “what did we spend, on which model, for whom”.

2.2 Tool Calls: MCP Server Portals

Model calls send data out. Tool calls take action, and an agent can execute thousands at machine speed with nobody reviewing any of them – the surface that deserves the most attention and usually gets the least.

MCP Server Portals collapse many upstream MCP servers behind one authenticated HTTP endpoint: the user authenticates through your Access identity provider, and the portal returns the tools from enabled servers – each call namespaced, credentialed, and proxied. That gives you:

• Identity at the door. Access policies decide who reaches the portal. Per server, Require user auth (on by default) decides whether calls run as the individual with their own credentials or under a shared admin credential. Prefer the former: it preserves permission parity with the underlying system.
• A curated catalog. Tools can be toggled off, renamed, and re-described; default_disabled exposes only an allowlist. An agent cannot call a tool it was never shown.
• Logs that name the tool – time, status, server, capability used, duration – Logpushable on Enterprise.
• Content inspection. Enable Gateway routing and portal traffic lands in your HTTP logs and can be DLP-scanned.
• OAuth that non-browser clients can complete. A CLI, SDK, or agent cannot follow Access’s browser redirect – it just gets a 302 with no token. Managed OAuth turns Access into a standards-compliant OAuth 2.0 authorization server issuing an opaque token rather than a JWT, while “Access enforces the same policies as a browser login.”

Two gotchas when writing the DLP policy. The portal re-originates each tool call, so Gateway sees the upstream server’s hostname, not the portal’s. And DLP AI prompt profiles do not apply to portal traffic; use standard profiles instead.

From visibility to enforcement. A portal only helps if agents use it. Per the MCP security updates, Gateway now identifies MCP traffic from the MCP-Protocol-Version header on TLS-inspected requests, exposed as the experimental.is_mcp selector (beta), and a dashboard separates portal traffic from direct device connections so shadow MCP servers become visible. Onboard the sanctioned ones, then close the bypass:

Action:   Block
Criteria: experimental.is_mcp and not(net.onramp.type == "mcp_portal")

That rule converts a portal from a convenience into a control. Detection depends on TLS inspection, so the blind spots above apply here too.

Why this got easier. The stateless MCP 2026-07-28 specification (MCP v2) adds Mcp-Method and Mcp-Name headers, so gateways and WAF rules see which operation is being performed without parsing JSON bodies; RFC 8707 audience binding stops a token minted for one server being replayed against another; and RFC 9207 issuer identification prevents authorization-server confusion. Cloudflare’s Agents SDK speaks it and the 2025 protocols with automatic fallback.

Context cost is a security lever. Portals enable Code Mode by default, replacing the tool list with code-execution tools whose JavaScript runs in an isolated Dynamic Worker, keeping credentials out of model context. Lighter optimize_context options exist: minimize_tools strips schemas behind an on-demand lookup tool (up to 5x savings), search_and_execute hides tools entirely. When exposing a hundred tools costs almost nothing, there is no reason to over-grant to save tokens.

Surface 3: Your Public AI Apps and APIs

Inspection point: AI Security for Apps.

This surface reverses direction: your own chatbot or API, receiving prompts from people you do not control. The AI Security for Apps reference architecture describes an AI-specific detection layer that complements – rather than replaces – the WAF, inline at the reverse proxy.

Discovery comes first. LLM endpoints are identified by heuristic analysis of traffic characteristics and it routinely surfaces endpoints nobody told the security team about. Three detection families then run in parallel, each against a model specific to its threat, which is what keeps inline inspection viable on latency:

• PII exposure – cf.llm.prompt.pii_detected, cf.llm.prompt.pii_categories
• Unsafe topics – cf.llm.prompt.unsafe_topic_detected, cf.llm.prompt.unsafe_topic_categories
• Prompt injection – cf.llm.prompt.injection_score, a 1–99 score where lower means higher risk

Discovery alone does not start scanning, and this is the step people miss. There are two switches: enable AI Security for Apps in Security Settings – off by default – then, in Web Assets, save the discovered endpoint with the cf-llm endpoint label. That label is a switch, not a selector: nothing is scanned until it is applied.

As one of the WAF traffic detections, it is sensor-and-responder: “detections are always on once enabled, even if you have not configured any security rules that use them.” Every request is scored whether a rule exists or not, and the fields combine with any other Rules language field:

(cf.llm.prompt.injection_score lt 20 and cf.bot_management.score lt 20)

Scoring without blocking lets you measure before you enforce. Log mode versus production mode is the deployment decision:

Start in log mode to tune thresholds, then move to custom rules; both can run at once during the transition, custom rules first.

Probabilistic Is Not Deterministic

A classic WAF rule is deterministic: it matches a known pattern and is auditable by reading it. AI threat detection is probabilistic – it reasons about intent in natural language, which has no signatures. Three consequences:

• You tune thresholds, you do not write patterns. No score catches everything and blocks nothing legitimate; you are picking a point on a curve, which is why log mode exists.
• Both error types are permanent. An attacker will eventually phrase something below your threshold, and a genuine user something above it. Plan the appeal path before you enable blocking.
• It does not replace the deterministic layer. Rate limiting, bot scoring, schema validation, and managed rulesets remain the floor.

Use both in a layered-security approach: deterministic controls for what a request is, probabilistic ones for what it appears to be trying to do.

Who Is Reading Your Content

AI Crawl Control answers a different question: not who is attacking your AI app, but who is consuming your content to build theirs. It gives per-crawler allow and block policies, tracks which crawlers honor robots.txt, and offers pay per crawl. The attribution dashboard adds crawl-to-referral ratios per operator – crawls versus visitors sent back, with observed extremes as lopsided as 50,000:1 – and classifies crawlers as Training, Search, or Agent. (The flip side is being legible to the agents you do want: Making Your Website AI Agent Ready.)

Mind the execution order. A terminating action in the Ruleset Engine ends evaluation immediately, and within a phase custom rules run top to bottom on first match. AI Crawl Control implements its blocks as WAF custom rules appended at the end of yours, so an earlier Allow or Skip lets a crawler straight past: “move the AI Crawl Control rule to the top of your WAF custom rules,” as the docs put it. Pay per crawl runs after WAF, so anything already blocked never reaches it.

One limit worth naming: Cloudflare knows whether an endpoint is protected, not what the application behind it can reach. The Wiz integration feeds protection status into the Wiz Security Graph, making “exposed and able to reach sensitive data?” answerable.

WAF rulesets, Advanced Rate Limiting, Bot Management, API Shield, and DDoS protection are the foundation underneath all of this, covered in The CISO’s Guide to Securing AI.

Surface 4: SaaS AI Providers

Inspection point: CASB – out-of-band, over API.

This is the surface that works when nothing is proxied: no device client, no gateway hostname, no TLS decryption. CASB connects to the provider’s API and inspects what is already there. Cloudflare One’s integrations include Anthropic and OpenAI directly, plus the AI features embedded in suites you already run – Gemini in Google Workspace, Copilot in Microsoft 365 – alongside Slack, GitHub, Bitbucket, Atlassian, Salesforce, ServiceNow, Box, Dropbox, AWS S3, and GCP Cloud Storage.

It answers different questions from inline inspection:

• Inline tells you what is being sent right now; CASB tells you what is already in the tenant – files, shared conversations, retained data.
• Inline needs traffic routed through Cloudflare; CASB works for unmanaged devices and personal networks, where it never will.
• Sharing settings, organization membership, seat sprawl, and retention are invisible on the wire, and visible only through the API.

Deploy it alongside inline controls, not instead of them.

Building and Deploying Agents Safely

Everything so far governs AI your organization consumes. This is about AI your teams build – and Cloudflare’s stated ambition is to be the best place to do it, with every primitive an agent or remote MCP server needs already on the platform: Workers and Containers for execution, Durable Objects for per-agent state, the Agents SDK for orchestration, AI Gateway and Workers AI for inference, Sandbox and @cloudflare/computer for isolated code, AI Search for retrieval, and Workflows for durable long-running work. Agents Week adds an Agent Development Lifecycle, live tracing with human-in-the-loop approvals, and an Agent Access Model for how agents reach resources on a user’s behalf. The security goal is to make that path the default one, and defaults only work if the platform supplies them.

Isolated execution. The Sandbox SDK 1.0 preview (@cloudflare/sandbox@next) runs code inside Cloudflare Containers. exec() takes an argument array and returns a process handle as soon as the process starts:

const process = await sandbox.exec(["npm", "test"]);
const result = await process.output({ encoding: "utf8" });
console.log(result.stdout, result.exitCode);

The same handle serves a short command or a long-running service, alongside logs(), waitForExit(), kill(), and PTY terminals. A sandbox keeps a stable ID while the container behind it can be replaced – and when that happens, processes fail closed rather than reattaching elsewhere. @cloudflare/computer sits a level above, routing work to a lightweight isolate or a full Linux container. For security teams the relevant property is that its operations are “gated, audited and observed” – the audit trail belongs to the runtime, not to whoever wrote the agent.

A reference pattern. The enterprise AI agent workspace diagram assembles these into something you can copy: work arrives through several channels (web app, chat, email, webhooks, schedules), Access authenticates browser sessions while each asynchronous channel validates its own signature, and the agent restores state from Durable Objects before calling approved models through AI Gateway and approved tools through an MCP Server Portal. Its governing principle is the whole design in one line: treat model output, tool output, and generated code as untrusted, and apply controls at platform boundaries rather than inside generated code.

An open-source starting point. Cloudflare OS is the agent workspace Cloudflare built for its own employees, open-sourced for your own account. Its security model is worth studying whether or not you deploy it: every agent “starts with access to nothing”; gatekeepers are service-specific Workers that mediate each resource access and hold the credentials, so agents never obtain long-lived tokens; and observation tracking propagates access restrictions through generated outputs, so a collaborator opening a document is checked against the underlying resources rather than inheriting laundered data.

How Cloudflare Runs This on Itself

The best argument that governed AI is not a tax on productivity is Cloudflare’s own internal stack. In one month it served 3,683 employees – 60% of the company, 93% of R&D – across 241.37 billion tokens, and merge request throughput went from roughly 5,600 a week to over 8,700. Sales saved more than 10,000 hours on manual work like territory planning and proposals; staff built over 4,000 apps and tools in 30 days, including a help desk dashboard agent written by the CIO; and AI reviewers flagged nearly a quarter of a million problems, blocked 16,000 merges, and caught architectural issues in close to 600 designs before a line of code was written.

None of it ran outside the controls. Every call goes through AI Gateway with zero data retention and a proxy Worker injecting provider keys server-side, so engineers never handle credentials; tools come from one MCP Server Portal aggregating 13+ servers and 182+ tools; and standards live in an Engineering Codex of RFCs using RFC 2119 keywords, promoted proposed → approved → enforced, that agents retrieve at the point of review. Of the five governance principles behind it, the fifth is worth adopting verbatim as policy language:

You should never have more permission with systems of record when using AI.

One implementation detail is directly transferable: user-controlled content is sanitized by stripping XML boundary tags entirely before it reaches a reviewer’s structured prompt.

Summary

Ask Every Provider the Same Questions

The four inspection points tell you what leaves; they say nothing about what the receiving provider does with it. That question is the same for a chatbot on Surface 1, a model API on Surface 2, and a SaaS tenant on Surface 4. Cloudflare’s Responsible AI page shows what a clear answer looks like: it does not train its own LLMs and does not use customer content to train any, its threat-detection models are trained on network traffic patterns rather than customer content, and third-party models on Workers AI carry vendor responsibility for EU AI Act compliance. It sits inside a Trust Hub of certifications, attestations, and sub-processor lists – use that as the shape of the questionnaire you send your own providers: retention, training use, sub-processors, data residency, zero data retention. “We have a CASB integration” and “we know what they do with our data” are separate assurances.

Where to Start

Order matters more than completeness:

1. Fix the on-ramps, and prepare properly for TLS decryption. The longest step, and the one that sinks projects when treated as a checkbox: deploy the device client through your MDM; distribute the root certificate to the OS trust store and to applications that keep their own; and write the Do Not Inspect policies for pinned and mTLS applications before your users find them.
2. Discover before you block. Run Gateway and the AI Security report for a few weeks, and classify applications rather than guessing.
3. Give agents a governed path for models – an AI Gateway custom domain, callers migrated off shared API keys, then Access on.
4. Give agents a governed path for tools – approved MCP servers behind a portal with a curated catalog and per-user auth.
5. Only then, close the bypass. Blocking non-portal MCP traffic before step 4 just pushes people onto unmanaged devices.
6. Run Surfaces 3 and 4 in parallel, and make the safe build path the easy one: sandboxed execution, zero-permission defaults, gatekeepered credentials.

The connecting idea across all four surfaces is that identity is the primary control, and the network is how you attach it. Every capability here – cf.user_id on a model call, per-user OAuth on a tool call, an Access policy on a gateway hostname – exists to answer one question: which human is accountable for what this agent just did?

Appendix: Let an Agent Drive Cloudflare

If you are going to secure AI, use it. Cloudflare Agent Setup wires the common coding agents into Cloudflare’s own MCP servers – a primary server covering 2,500+ API endpoints via code mode (about 1,000 tokens instead of 1.17 million), plus focused ones for docs, observability, AI Gateway logs, CASB findings, DEX troubleshooting, analytics, and audit logs – with the Cloudflare One stack skills for Zero Trust work.

For skills beyond Cloudflare, skills.sh is an open, vendor-neutral registry supporting 19+ coding agents. Read what a skill does before installing it.

Start read-only. Scope the API token. A read-only token is already most of the value: an agent that can read your Gateway logs, AI Gateway spend, and CASB findings can investigate an anomaly and draft the rule, while a human still applies it.

Disclaimer

Educational purposes only.

This blog post is independent and not affiliated with, endorsed by, or necessarily reflective of the opinions of Cloudflare or any other entities mentioned. Product capabilities described here reflect publicly available documentation and blog posts at the time of writing; several features referenced are explicitly in preview or beta and may change.

This blog post was partially drafted and refined with AI assistance.