Cloudflare: the X-ray deck

The full X-ray of Cloudflare · keys ← → · F fullscreen · A all slides. The plain-text version is this page's markdown twin (index.md).

X-rayed by RiskMandate

Cloudflare

The connectivity cloud that hosts AI agents: the Agents SDK on Durable Objects, Workers AI inference, AI Gateway and managed MCP servers.

Sources read on 2026-11-07 · web-summit.sgit.ai/xray/cloudflare

What it does

Cloudflare

Cloudflare runs a global network and security platform, now pitched as one platform for apps, agents and workforce. For agents it offers the Agents SDK, which hosts each agent as a Durable Object with its own storage, scheduling and tools (browser, sandbox, web search, MCP, payments), Workers AI for serverless model inference, and AI Gateway to log, cache, route, rate-limit and budget model calls across providers. It also runs managed remote MCP servers that let outside agents read and change a Cloudflare account through its API.

Sources: s1, s2, s3, s4, s19

Its AI agents

What acts on its own

Agents SDK agentAn agent a developer builds and Cloudflare hosts: each agent is a Durable Object with a durable identity, local SQL storage, real-time connections, scheduled work and recoverable execution; a harness (Pi, OpenCode or Think) runs the loop that calls models and tools. Reached by chat, voice, email, Slack and webhooks.
  • Calls Workers AI models, AI Gateway catalog models and vendor models (OpenAI, Anthropic, Google) through one createAI provider
  • Connects to external MCP servers with addMcpServer and passes their tools into model calls, with OAuth or bearer tokens
  • Uses a workspace, a Linux sandbox, web fetch, web search, a browser (Browser Run), AI Search and Code Mode
  • Pays for resources and tools through x402 and the Machine Payments Protocol
  • Keeps state in SQL storage, schedules future work, hibernates when idle
Cloudflare API MCPCloudflare's managed remote MCP server at mcp.cloudflare.com: lets an outside agent (Claude, Cursor, Claude Code and others) read and change a Cloudflare account across the whole Cloudflare API, authorised by OAuth or an API token. Product-specific servers (docs, containers, Browser Run, DEX, CASB) sit alongside it.
  • search() and execute() over more than 2,500 Cloudflare API endpoints (DNS, Workers, R2, Zero Trust and every other product)
  • Runs model-written JavaScript against the API inside an isolated Dynamic Worker sandbox
  • docs() to search Cloudflare developer documentation
  • Reads account configuration, makes suggestions and can make the suggested changes
Workers AI inferenceThe serverless inference service agents call: 50+ open-source models (including GLM-5.3, an agentic coding model with a 1M-token context window) on GPUs across Cloudflare's network, invoked from Workers, Pages or the Cloudflare API.
  • Runs text, image and embedding models for agents through the AI binding or REST API
  • Processes prompts and returns outputs; documented as zero data retention for standard inference
  • Serves as the default model for Agents SDK examples

Use case · Workers AI inference

Aug to Sep 2026: GLM-5.3 answers held other customers' data

Reach
  • The customer's prompt: very long context sent by an agent or app to GLM-5.3 (affected prompts were longer than 681,280 tokens) data
  • The shared KV cache pool in GPU memory: fixed-size pages reused between requests and not zeroed; the prefill pool held 681,280 tokens against an advertised 1,048,576-token context system
  • Other customers' prompts and partial generations left in stale cache pages from requests made shortly before data
  • Responses delivered to a different customer: 155 responses between 27 August and 9 September 2026, returned with HTTP 200 and coherent text outside
  • Where a response is kept afterwards: AI Gateway logs (prompt and response, on by default for each gateway) and the agent's own storage data
Mandate (illustrative)
  • As documented on the Workers AI data usage page: inputs and outputs are Customer Content, Cloudflare does not make it available to other Cloudflare customers, and standard inference keeps no inputs or outputs after the response
  • Illustrative: the customer's agent sends its own project context and gets back an answer built only from its own request
Gap
  • The model was advertised with a 1,048,576-token context while the cache pool held 681,280 tokens; the mismatch was known before launch and pre-launch tests checked only status codes and performance, not output, so the isolation between customers rested on an untested assumption.
  • Nothing in the response marked the leak: the client got HTTP 200 and a coherent reply, so another customer's data could flow into an agent's context and into stored logs without either customer seeing it.

Use case · Cloudflare API MCP

A coding agent changes a Cloudflare account through MCP

Reach
  • The whole Cloudflare API through two tools: more than 2,500 endpoints across DNS, Workers, R2, Zero Trust and every other product system
  • Model-written JavaScript run against the API client inside an isolated Dynamic Worker sandbox code
  • DNS records and Worker deployments the agent can create or change system
  • Account configuration, logs and analytics the agent can read data
  • Zero Trust and security configuration, reachable through the same API system
  • The grant itself: OAuth permissions chosen at connect, or a user or account API token passed as a bearer token for automation people
Mandate (illustrative)
  • Illustrative: read the zone's configuration and add one DNS record for one site
  • Illustrative: no changes to Zero Trust policies, Workers or other zones without the owner's approval
Gap
  • One server covers the entire API, so the only boundary is the permissions chosen at OAuth time or on the token; a broad grant puts security policy and every product within reach of a task that needs one record.
  • Changes are made by code the model writes and runs in one execute() call; the docs describe the agent making suggested changes for you, with no documented per-change approval on this server.

Use case · Agents SDK agent

A support agent with tools, a browser and payments

Reach
  • The agent's own state: SQL storage, chat history and an AI Search knowledge base it can write back to data
  • External MCP servers (for example GitHub), whose tools go into model calls, acting on behalf of the end user with an OAuth grant outside
  • A browser that keeps tabs, cookies and login sessions between turns, and can open sites the agent serves itself outside
  • Payments: x402 (stablecoins such as USDC) and the Machine Payments Protocol, paid programmatically with no pre-shared key; human approval on the x402 client is optional money
  • A Linux sandbox for shell commands and scripts; it cannot read the agent's storage or bindings and reaches the internet only when allowed code
  • Models from many providers through AI Gateway, which holds the vendor keys or bills through Unified Billing money
Mandate (illustrative)
  • Illustrative: answer customers from the knowledge base and read issue activity; no actions in customers' own accounts
  • Illustrative: spend on models and paid services within a monthly budget, and any single payment over a threshold only with a person's approval
Gap
  • The browser keeps logins between turns, and MCP tools act with the end user's grant, so the agent can reach into accounts that the support task only needs to read about.
  • Human approval for x402 payments is optional on the client; unless the developer sets it, the agent can pay a 402 challenge on its own.

The simulation · Aug to Sep 2026: GLM-5.3 answers held other customers' data

Each action, placed against the mandate

  1. 27 August 2026: GLM-5.3 launches on Workers AI with a 1,048,576-token context and a 681,280-token prefill pool; the mismatch is known and long-context tests return success codes in the gap
    The record: RiskMandate's record shows the advertised context and the cache pool disagreeing, and that the evidence for safe handling was status codes, not checked output.
  2. (illustrative) A customer's coding agent sends a prompt of about 700,000 tokens with its project context to @cf/zai-org/glm-5.3 in the mandate
  3. The engine rejects the over-length prompt internally, swaps in a one-token placeholder and still hands off to decode, which attends over reserved pages still holding earlier requests' data in the gap
    The record: RiskMandate's record shows other customers' prompts inside this request's reach, against the documented commitment that Customer Content is not made available to other customers.
  4. The reply returns HTTP 200, coherent, containing other users' content; 155 responses are affected between 27 August and 9 September in the gap
    The record: RiskMandate's record shows data leaving one customer's boundary for another with no error raised, so neither side had a signal that the mandate was broken.
  5. (illustrative) The receiving agent stores the reply in its conversation state, and the gateway's default logging keeps the prompt and response in the gap
    The record: RiskMandate's record shows another customer's content now persisted in this customer's logs and agent storage, outside the zero-retention path.
  6. 8 September, 23:11 UTC: a security researcher reports the leak through HackerOne; 9 September 13:22 incident declared, reproduced with two accounts; 14:00 model set private in the mandate
  7. 9 September: pool resized and engine patched, validated against the researcher's script; model restored at 19:40; 26 October coordinated disclosure, no evidence of deliberate exploitation found in the mandate

What RiskMandate gives

RiskMandate is never in the request path: read-only by design.

It measures what your agents can actually reach, evidences the controls that contain them, prices the exposure, and produces that record.

riskmandate.ai/llms.txt

Sources

Every fact, with its source and the date read

And 32 more on the X-ray page.

The questions we would ask

We have not asked them yet

  1. After the GLM-5.3 exposure, what tells a Workers AI customer, per request, that the answer was built only from its own data, and were the customers who received or supplied the 155 affected responses told which requests were involved?
  2. Can a Cloudflare API MCP server session be limited to one zone and read-only by default, with each write held for a person's approval, rather than relying on the OAuth scopes chosen at connect?
  3. Is every action an agent takes through the MCP server recorded in the account audit log as that agent, separately from the human who granted it?
  4. For agents that pay through x402 or MPP, can an account set a hard spending ceiling and mandatory approval that the developer cannot leave optional?
  5. Browser sessions keep cookies and logins between turns: which controls stop an agent from using a logged-in session for something its task did not need, and is that use logged?

The full X-ray · What happened: how this X-ray was made · built by xray@web-summit.dinis

For an agent: this page is https://web-summit.sgit.ai/xray/cloudflare/deck/index.html (markdown: https://web-summit.sgit.ai/xray/cloudflare/deck/index.md). Site index for agents: https://web-summit.sgit.ai/llms.txt. Source: https://github.com/SGit-AI/SGit-AI__Website__Web-Summit (release branch dev). Identity of the agent that runs this site: https://web-summit.sgit.ai/agent/index.html.