Cloudflare didn't issue API keys to its employees—and it was the right call

The most dangerous part of the internal AI boom isn’t the models’ poor responses. It’s the moment when a sales rep asks for several API keys, access to a dozen production systems, and admin privileges in the deployment pipeline to build their own “SuperApp.”

Cloudflare decided not to ban such initiatives. But it also didn’t hand out access to just anyone. This is the main lesson from Cloudflare OS: AI should be scaled not by trusting every developer, but through an architecture that prevents users from accidentally gaining unnecessary access.

At first, the company took a rather unconventional approach. Instead of giving everyone a code-generation harness, it encouraged employees to send routine tasks to a shared “magic AI email bot.” A small team at that address handled the work using AI tools.

It doesn’t sound very high-tech—and that’s exactly why the approach is useful. This “manual” layer made it possible to gather real business requests and gradually turn them into a set of repeatable skills. Otherwise, the organization would quickly end up with a flood of “vibe-coded” applications that only look for a problem after they’ve been written.

The next layer is accountability. At Cloudflare, AI is viewed as a tool and a set of tools, not as a new employee. The person who commissioned or launched an agent is responsible for its results, quality, testing, and workflow. If an employee leaves, responsibility for their agents passes to their manager.

To ensure this isn’t just a hollow statement, domain experts describe the correct way to work in the Engineering Codex. It’s not just a list of prohibitions: the Codex sets out best practices. Individual agents then review merge requests, technical designs, and incident reports to ensure they comply with these rules.

The most powerful concept is access control. Every agent and every application starts with zero privileges. Internet access and specific resources are only explicitly enabled, and access is limited by the current user’s permissions. If an agent is shared, it operates with the recipient’s permissions, not the author’s.

For external systems, Cloudflare uses Gatekeeper—an intermediary service that stores OAuth credentials, enforces policies, and logs actions. It can allow an agent to read issues in only one repository, hide specific fields, limit the frequency of requests, or require confirmation before a merge.

What’s particularly interesting is that the system attempts to pass restrictions along with the data. If an agent reads a sensitive resource, the resulting data retains information about its origin and access level. Gatekeeper can then prevent that result from being passed to another agent, block a new user from joining, or stop data from being sent externally. This is no longer a simple “does the user have access” check, but rather transitive control over what has been built based on the data.

But this is precisely where the unknown territory begins. Cloudflare OS is described as an open platform, but its architecture relies heavily on Workers, Cloudflare Access, and other Cloudflare products. Without significant adaptation, it will likely be difficult to use this approach outside of this ecosystem. Furthermore, it is still unclear exactly how the “propagation” of permissions and the sensitivity of input data is technically implemented: through deterministic rules, AI mechanisms, or a combination of both.

There is also an organizational limitation: one cannot expect an employee without a technical background to understand risks at the level of a developer or architect. Therefore, human responsibility alone is not a safeguard. It works only in conjunction with opinionated rules, gateways, audits, and secure default settings.

For companies, the practical conclusion is simple: before granting everyone access to application generation, it’s worth creating a secure channel for collecting tasks, defining “best practices” for key domains, and removing API keys from the user workflow. A good AI platform layer should protect people from their own careless decisions, rather than requiring them to be security experts.

If your employees needed agents to work with production data tomorrow, would you give them a builder first, or would you set up Gatekeeper first? Source: Hacker News - Newest: ""AI" "LLM""