Cloudflare’s new internal data stack is a bet that “how built” matters as much as what was built: Town Lake gives employees a unified SQL layer over scattered operational data, while Skipper adds a natural-language interface on top.
The important part is not that Cloudflare added an AI agent. The important part is the layer underneath it. Cloudflare says it first had to make its data findable, permissioned, auditable, and queryable across systems before a plain-English agent could be trusted to answer internal questions.
That is the practical lesson for security operations and privacy risk. An AI interface over messy data does not fix the mess. It can make the mess faster.
What changed#
Cloudflare described two internal tools: Town Lake, a unified data analytics platform, and Skipper, an AI data agent that runs on top of it.
The source problem was data sprawl. Cloudflare says its operational data lived across production databases, ClickHouse clusters, Kafka streams, Google Cloud buckets, BigQuery datasets, and a long tail of pipelines. A simple business or operational question could require knowing the right system, the right credentials, the right query language, and whether the answer came from sampled data, fresh data, or stale data.
That distinction matters. Cloudflare gives the example of dashboards versus billing. Downsampling can be reasonable when a dashboard needs to load quickly. It is the wrong default when usage is being computed for an invoice. The same split applies to investigations: sampled data can help exploration, but it can be dangerous if someone treats it as complete evidence.
Town Lake is Cloudflare’s attempt to put one query surface over that landscape. The company says it uses Apache Trino so a single SQL query can join across systems such as Postgres, ClickHouse, and Iceberg tables on R2 without first materializing everything into another system.
For colder and warmer data, Cloudflare describes using Apache Iceberg on R2. Iceberg gives the platform table-like behavior over object storage, including schema evolution, time travel, partition evolution, and compaction as data ages. In Cloudflare’s description, recent usage can be stored at finer resolution and older usage can be compacted to coarser intervals while remaining queryable.
Cloudflare also names DataHub as the metadata layer. That is where table descriptions, column descriptions, owners, lineage, and glossary terms live. This is not a decorative catalog. For a system like this, metadata is part of the control plane. If users cannot tell what a table means, who owns it, and what feeds it, the unified query layer can still produce confident wrong answers.
Skipper sits on top of Town Lake. Cloudflare’s stated goal is to let authorized employees ask plain-English questions and get correct, auditable answers without needing to know SQL. The examples in the source range from revenue and billing questions to security-oriented queries such as Bot Management scoring events from a specific ASN.
Why it matters for security operations and privacy risk#
The post is a clean example of a pattern many large organizations hit: the more telemetry a company produces, the harder it becomes to use that telemetry safely.
Cloudflare says it processes more than a billion events every second and operates across 330+ cities in 120+ countries. At that scale, the operational issue is not merely storage. It is knowing which data can be trusted for which decision.
Security operations depend on that distinction. An analyst looking at abuse patterns, bot signals, account metadata, or support context needs more than access to “the data.” They need freshness, lineage, retention, sampling status, and permission boundaries. Otherwise the query result becomes a false anchor.
The privacy risk moves in the same direction. A unified analytics platform can reduce random credential-sharing and tribal access patterns. It can also concentrate sensitive visibility into one powerful interface. Cloudflare’s answer, according to the post, is to bake in governance: automatic detection of personally identifiable information, sensitive tables locked down by default, auditable access, and time-bounded permission grants.
Those controls are the difference between “internal AI assistant” and “fast path to oversharing.” Skipper is only as safe as the authorization and metadata model beneath it. If the agent can answer a question, the platform still needs to prove the user was allowed to ask it, the data source was appropriate, and the answer can be traced.
This is also where open source security and internal platform security meet. Apache Trino, Apache Iceberg, and DataHub are not magic shields. They are components in a trust model. Their value depends on how access rules, table ownership, lineage, and operational checks are implemented around them.
What to check before copying this model#
The useful question is not “should every company build this?” Most should not copy Cloudflare’s architecture one-to-one. The useful question is what must be true before a unified data layer or AI data agent becomes safe enough to rely on.
Start with the data classes. Which questions require unsampled data? Which can use approximate or downsampled data? Billing, incident response, fraud review, and legal or compliance work usually need stricter treatment than exploratory dashboards.
Then check identity and access. A unified interface raises the cost of weak permissions. The system should know who is asking, what group they belong to, what task justifies access, and when that access expires. Permanent broad access is the failure mode.
Metadata quality is next. If table owners, descriptions, lineage, and retention rules are missing or stale, a natural-language layer will not repair the gap. It may hide it. A user may ask a plain question and receive a polished answer built on misunderstood data.
For AI agents specifically, auditability is the hard requirement. The platform should preserve what was asked, which sources were used, what query was executed, what permissions were checked, and what answer was returned. Without that chain, it is difficult to debug bad answers or investigate improper access.
Practical operational checks:
- Identify which datasets are sampled, delayed, compacted, or approximate.
- Mark sensitive tables and columns before exposing them through broad query tools.
- Require ownership and lineage for critical datasets.
- Use time-bounded grants for exceptional access.
- Log agent prompts, generated queries, source tables, and returned outputs.
- Test whether the agent refuses questions that the user could not answer through direct SQL.
This is the same lesson as recent supply-chain work: artifacts only help when they become operational. See also GigaTap’s note on OpenSSF’s April signal: https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational
What not to overclaim#
Cloudflare’s post is an architecture story, not an independent security audit. It says what the company built and why, but it does not prove that every permission rule, PII detector, metadata entry, or AI response is correct in production.
Do not read the post as evidence that natural-language analytics are automatically safe at scale. The source supports a narrower claim: Cloudflare recognized that an AI data agent needed a governed platform underneath it, and it designed Town Lake around unified access, metadata, lineage, and auditability.
That is still a meaningful signal. Many organizations try to add AI at the interface layer while leaving data quality and access control as someone else’s problem. Cloudflare’s write-up points the other way: first make the data layer coherent, then let more people ask questions.
The trade-off remains real. Centralization can reduce chaos, but it also creates a high-value control plane. If the access service, metadata catalog, or agent policy layer fails, the blast radius is larger than a single dashboard or database credential.
For readers evaluating similar systems, the operational checks matter more than the agent demo. Ask how built, not just what shipped. The answer should include data lineage, permission expiry, sensitive-data handling, sampling status, and audit trails. If those parts are vague, the AI layer is not the innovation. It is the risk multiplier.