cloudflare-gateway

How Cloudflare detects MCP traffic and helps secure it (opens in new tab)

AI agents change the risk model for resource permissions because they make nondeterministic decisions and can repeat actions at machine speed. A mistaken judgment that a human might quickly catch can become thousands of harmful operations before anyone notices. Cloudflare’s new Cloudflare One capabilities aim to detect MCP traffic, identify its users and servers, and enforce approved routes through MCP Server Portals. ## Why AI Agents Require New Controls - Traditional permissions assumed users would apply judgment and act at a limited human pace. - AI agents can invoke tools repeatedly and indefinitely. - A single incorrect decision can rapidly propagate across databases, SaaS systems, or infrastructure. - MCP makes it easy to connect clients such as Claude Code, Codex, Cursor, OpenCode, and VS Code to approved or unapproved tools. - Direct MCP traffic can resemble ordinary HTTPS because MCP does not require a standard hostname or `/mcp` path. ## Anatomy of an MCP Tool Call An MCP request appears differently at three points: - **Client:** The agent decides to invoke a tool and supplies arguments. - **Network:** The request is transmitted as an HTTP transaction containing JSON-RPC. - **Server:** The server authenticates, validates, and dispatches the request to a tool handler. Useful protocol signals include: - Destination hostname and path - Authorization credentials - `MCP-Protocol-Version` - `Mcp-Method` - `Mcp-Name` - JSON-RPC request `id` - Tool arguments in `params` The tool name indicates the intended operation, while the arguments may contain sensitive data such as source code, customer information, search queries, or infrastructure-changing instructions. Responses can also contain sensitive results, making both request prevention and response inspection valuable. ## Controls Inside the MCP Client Client hooks can intervene after the model selects a tool but before the request is serialized. - Enforce server allowlists - Require confirmation for sensitive operations - Remove sensitive data from arguments - Support local `stdio` MCP servers that never generate network traffic The main limitation is operational: organizations must implement controls across every client employees use. Client telemetry also cannot provide a complete inventory unless the organization manages all relevant clients and devices. ## Controls at the Network Boundary A secure web gateway with TLS decryption can inspect remote MCP traffic independently of the client. - Associate requests with users and devices - Inspect destinations and MCP protocol headers - Detect direct connections outside approved MCP Portals - Block unauthorized traffic before it reaches the server - Use data loss prevention scanning to inspect JSON-RPC methods and arguments Network controls provide the broadest visibility into remote MCP usage, but they cannot see local `stdio` calls or traffic that bypasses managed network paths. ## Controls at the MCP Server The server has the deepest execution context because it knows the authenticated caller, parsed message, resolved tool, and validated arguments. Server-side middleware can: - Authorize users for specific tools - Apply rate limits - Inspect arguments - Log outcomes - Block requests before tool execution Cloudflare’s WriteGuard applies this approach to internal MCP servers by assigning tools risk tiers and enabled or disabled states. It can allow reads, attach attribution and audit events to approved writes, or block critical actions before their handlers run. Because enforcement occurs on the server, users cannot bypass it by changing clients or disabling local hooks. ## Layered MCP Security Each control point has a different strength: - **Client controls:** Earliest intervention and support for local MCP, but limited coverage. - **Network controls:** Broadest visibility into remote traffic and unmanaged MCP connections. - **Server controls:** Richest context and final prevention point before execution. A layered strategy can protect sensitive data before it leaves a device, identify shadow MCP usage, require trusted Portal-based access, and prevent unauthorized tools from executing.

Cloudflare Internal DNS is now generally available (opens in new tab)

Cloudflare Internal DNS is now generally available as a unified platform for public and private DNS. It combines recursive resolution, authoritative private zones, DNS policy enforcement, and Zero Trust controls on Cloudflare’s global network. The goal is to eliminate fragmented DNS systems and simplify split-horizon management without duplicated configurations or synchronization drift. ## Problems with Traditional Internal DNS - Organizations often manage public DNS, internal DNS, and cloud-provider DNS separately. - Separate control planes create inconsistent policies, limited visibility, and operational overhead. - Split-horizon DNS typically requires parallel environments that can drift and cause outages. - Legacy appliances introduce hardware refresh cycles and scaling constraints. ## Unified DNS and Zero Trust - Public and private DNS share one platform, API, audit trail, and policy layer. - Internal DNS is included for Enterprise customers using Cloudflare Gateway. - Gateway policies determine which users and devices can resolve specific DNS views. - Private name resolution becomes part of the broader Zero Trust architecture. ## Internal DNS Architecture Cloudflare Internal DNS has two main components: - **Gateway Resolver** - Performs recursive resolution and evaluates DNS policies. - Can filter queries or redirect them to different upstream sources. - Provides centralized logging, auditing, and policy management. - **Internal Authoritative DNS** - Serves records for private zones using Cloudflare’s authoritative DNS infrastructure. - Stores resources such as internal applications, databases, and service endpoints. The main configuration objects are: - **Internal Zones:** Authoritative records for private resources. - **DNS Views:** Resolution contexts containing one or more zones. - **Resolver Policies:** Gateway rules that route matching queries to a specific view. - **Zone references:** Allow one shared zone to be reused across multiple views without duplicating records. ## Query Resolution and Change Propagation - Queries first reach the Gateway Resolver for policy evaluation. - Matching policies route queries to an internal DNS view. - Blocked queries are dropped. - Unmatched queries use public resolution through 1.1.1.1. - Views can fall back to public DNS when a name is not found internally. - Changes from the dashboard, API, or Terraform use the same DNS Records API. - Records are validated, persisted, replicated globally, and propagated within seconds as caches are invalidated. ## Getting Started - Enterprise customers using Gateway can access Internal DNS from **Networking → Internal DNS**. - Initial setup generally requires: - Creating an internal zone and records. - Creating a DNS view and associating the zone. - Creating a Gateway resolver policy that routes users or devices to the view. - Terraform is supported and follows the same API ingestion and propagation path. ## Connectivity Cloud Integration - Internal DNS works with Cloudflare One Client, DoH, DoT, standard DNS, PAC files, and Cloudflare WAN. - Cloudflare WAN enables devices across branches, data centers, cloud environments, and remote networks to resolve internal names without installing the client on every device. - The service extends Cloudflare’s existing Connectivity Cloud rather than operating as an isolated DNS product. Cloudflare’s recommendation is to consolidate public DNS, private DNS, and DNS security policies on one control plane, particularly for organizations already using Cloudflare Gateway or WAN.

Announcing Claude Compliance API support with Cloudflare CASB (opens in new tab)

Cloudflare is adding Claude Compliance API support to CASB, giving security teams visibility into Claude usage without endpoint agents or inline traffic inspection. The integration scans Claude organizations, projects, conversations, files, and artifacts for sharing issues and sensitive data, then surfaces findings in the Cloudflare dashboard. It also connects those findings to Cloudflare Gateway policies so teams can move from detection to enforcement. ## The Security Challenge of Enterprise AI - AI adoption has outpaced governance, leaving organizations with limited visibility into sanctioned tools. - Traditional controls may block unauthorized applications but cannot inspect activity inside approved AI platforms. - AI-specific risks include: - Employees entering customer or confidential data into prompts - Developers exposing API keys - AI-generated content containing company secrets - Files and data being shared through persistent conversations and agent workflows - Effective protection must cover the full lifecycle of AI data, including API usage, content handling, and data stored within applications. ## Cloudflare’s Layered AI Security Model - **Cloudflare AI Gateway** monitors requests, token usage, and model performance while supporting rate limits, caching, and routing controls. - **Cloudflare Gateway and Data Loss Prevention** inspect AI traffic and can block prompts containing personally identifiable information or confidential material. - **Cloudflare Access with MCP server portals** protects connections between agents and corporate systems, with centralized access control and audit logging. - **Cloudflare CASB** scans data stored inside Claude for misconfigurations and sensitive content through API integrations. ## Claude Compliance API Findings Cloudflare CASB connects to Anthropic’s Compliance API and displays findings alongside those from applications such as Microsoft 365, Google Workspace, and Salesforce. - **Projects:** Detect projects shared with an organization or selected users and groups. - **Project attachments:** Identify files and documents violating DLP policies. - **Chat files:** Scan user-uploaded and provider-generated files. - **Chat messages:** Inspect prompts and provider responses for sensitive data. - **Artifacts:** Detect sensitive information in AI-generated documents and files. - Findings are categorized, prioritized by severity, and handled through existing triage, assignment, and remediation workflows. ## Coverage for Claude Enterprise and Platform - For **Claude Enterprise**, CASB retrieves information about organizations, projects, chats, roles, messages, and uploaded files using read-only endpoints. - For **Claude Platform**, it continues to monitor member and workspace changes, API key creation, and file creation or download events. - Support for the Claude Platform Activity Feed is planned for a future release. ## From Detection to Enforcement - A finding such as a sensitive file upload can be converted into a Cloudflare Gateway policy. - Administrators can: - Block uploads to Claude for specific users - Restrict access to Claude entirely - Limit application functionality until the issue is resolved - This combines CASB’s visibility into stored data with Cloudflare’s inline policy enforcement. ## Getting Started - Organizations need a Claude Enterprise account. - They must request Compliance API access from Anthropic. - Once access is granted, the integration can be connected through Cloudflare CASB. Cloudflare’s recommendation is to combine CASB monitoring with Gateway, DLP, AI Gateway, and Access controls to govern AI usage across both traffic and stored data.