techlist.io
KREN

Cloudflare/AI Agents

24 posts

cloudflare3 min readCurated summary

How Cloudflare detects MCP traffic and helps secure it

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.

Read original(opens in new tab)
AI AgentsModel Context ProtocolAccess ControlData Loss Prevention+4
cloudflare3 min readCurated summary

Everything we launched during Agents Week

Cloudflare’s Agents Week presented agents as a new class of software requiring more than advanced models: they need runtimes, identity, orchestration, memory, observability, and security. Across five days, Cloudflare introduced infrastructure and tools for building, deploying, governing, and connecting agents to the web. The broader conclusion is that an “Agentic Internet” must support cooperation between humans and autonomous software while preserving control, trust, and openness. ## Agent Runtime and Infrastructure - Cloudflare introduced `@cloudflare/computer`, a runtime that lets agents select suitable computing environments rather than relying solely on containers. - Workers RPC now supports communication between Python and JavaScript Workers. - Cloudflare detailed efforts to run models such as Kimi and GLM more efficiently while maintaining quality, reliability, and safety. - The Billable Usage API provides programmatic access to Cloudflare product costs and usage. - Workers and Containers gained inbound TCP and gRPC support, enabling real-time applications such as voice AI backends. ## From Prototypes to Production with the ADLC - Cloudflare proposed the Agent Development Lifecycle (ADLC) as an evolution of the traditional Software Development Lifecycle for agent-based software. - Cloudflare Agents provide live run monitoring, tracing, replay, and human approval workflows. - Local tracing helps agents and developers debug Workers before deployment. - Cloudflare Wallets give agents programmable, secure capabilities for participating in transactions. - Programmable CI/CD pipelines can run across millions of repositories and use agents to diagnose failures and prepare fixes for review. - Cloudflare described internal AI-powered engineering workflows, including automated standards enforcement and an Astro software factory that reduced GitHub issue-management toil. ## Identity, Security, and Governance - The Agent Access Model defines how agents can access services and resources on behalf of users. - Cloudflare OS embeds AI into internal work while retaining security and human oversight, and its platform was open-sourced for building applications and automations. - Identity-aware analytics connect AI activity to users and systems, helping detect anomalous behavior and unexpected spending. - WriteGuard adds fine-grained controls to MCP servers to restrict dangerous or unwanted tool calls. ## Building an Agentic Internet - Cloudflare outlined an Internet that is readable, discoverable, callable, and payable, allowing publishers to control access while enabling agents to interact and transact. - WebMCP gives websites and web applications a simple interface that agents can discover and use. - Answer Engine Optimization (AEO) adapts SEO practices for content surfaced by AI agents. - Kitesurf is an agent-focused browser running in V8 isolates, prioritizing efficiency over pixel-perfect rendering. - MCPv2 simplifies the deployment and scaling of agentic applications. - Cloudflare AI Search turns websites and files into searchable, agent-ready data sources. ## Observing the Agent Ecosystem - Cloudflare argued that bot behavior should be evaluated through continuous trust rather than assuming bots are inherently harmful. - Workers AI and AI Gateway are being unified into a single AI control plane with one binding, wallet, and dashboard for model access. - New Cloudflare Ambassadors and Community Engineers programs support community leaders and open-source maintainers, alongside an additional $1 million in open-source funding. - Radar Researcher lets users explore Internet data through natural-language questions and interactive charts. Cloudflare’s vision is an Agent Cloud combining execution infrastructure, an increasingly automated development lifecycle, secure identity and access, agent-ready web protocols, and strong human communities. Building agents successfully will require treating them as participants in a broader computing ecosystem—not merely as model-powered features.

Read original(opens in new tab)
AI AgentsCI/CDModel Context ProtocolCloudflare Workers+4
cloudflare3 min readCurated summary

Unveiling good and bad behaviors on the Agentic Internet

The Internet contains a mix of human, automated, and hybrid traffic, so classifying visitors simply as “good humans” or “bad bots” no longer works. Cloudflare argues that website owners should evaluate continuous behavior and build trust over time, rather than rely only on isolated risk checks. Its strategy combines transparent bot classification through BotBase with behavioral detection through Precursor. ## Risk and Trust Are Different - **Risk** measures how likely a request or action is to be harmful, often based on a momentary event. - **Trust** develops over time through reputation and observed behavior. - A suspicious action should not automatically lead to rejection if the actor has an established, trustworthy identity. - Cloudflare’s goal is to create incentives for safer behavior, from blocking malicious activity to enabling beneficial automated participation. ## Verified Bots and Transparency - Cloudflare defines verified bots and agents through two requirements: - They honestly declare who they are. - They do not abuse the trust they receive. - Transparency helps site owners decide which behaviors and data uses to permit. - BotBase is designed as a directory of all known bots and agents, not just approved ones. - Actors that violate expectations can lose their verified status and become harder to trust across Cloudflare’s network. ## Continuous Detection with Precursor - Precursor is a client-side system that continuously analyzes behavior throughout a session. - Its JavaScript is injected at the CDN, so customers do not need to manually place or rerun detection code. - Unlike CAPTCHAs and other one-time challenges, Precursor evaluates behavior in context over multiple pages. - Continuous analysis makes it more expensive for bot developers to imitate human behavior across an entire session. ## What Cloudflare Has Observed - In a 24-hour snapshot, Precursor processed **206 million evaluation events across 73,438 zones**. - Suspicious behavior frequently begins in the middle of a session, meaning point-in-time checks can miss it. - A single session may shift between human and automated behavior, such as when a user hands part of a shopping journey to an agent. - Site owners therefore need classifications based on use case, purpose, and data usage rather than a simple human-versus-bot decision. ## Understanding Human Cursor Behavior - **Precursor Trace** is an interactive demonstration of part of Precursor’s detection process. - It examines cursor acceleration, corrections, rhythm, and movement texture. - The demo illustrates how behavioral signals can distinguish natural interaction from automated movement. ## Adaptive Intelligence - Cloudflare indicates that its bot detection engines will soon provide more adaptive outcomes for requests identified as automated. - The excerpt ends before detailing how this upcoming capability will work. Website owners should treat automation as a spectrum: verify transparent actors, monitor behavior continuously, and make decisions based on trust, intent, and use case rather than isolated signals.

Read original(opens in new tab)
AI AgentsCloudflareJavaScriptCdn+3
cloudflare3 min readCurated summary

Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers

Cloudflare argues that AI agents need a browser optimized for machine tasks rather than human browsing. Chromium provides far more functionality than agents require while consuming too much memory and compute, limiting accessibility and scalability. The company therefore built Kitesurf, a lightweight browser running entirely on Workers and designed for agentic workloads. ## Why Cloudflare Built a New Browser - Cloudflare had repeatedly considered building a browser but previously found the technical investment difficult to justify. - Recent advances in its Developer Platform changed the equation: - Mature WebAssembly support in Workers - Dynamic workers - SQLite-based Durable Objects - Worker-to-worker RPC and service bindings - Improved Node.js compatibility and higher platform limits - Growing demand for AI browser automation exposed Chromium’s limitations: - High CPU and memory consumption - Expensive dedicated browser instances - Poor scalability for large numbers of agents ## Designing for Agents Instead of Humans - Agents prioritize: - Low token counts - Large context windows - Scalability and performance - Low operating costs - Structured, machine-readable content - They do not need many human-oriented features, such as: - Tabs, themes, extensions, and device synchronization - Pixel-perfect rendering - Smooth 60-frame-per-second scrolling - AI browser security requires a different threat model, with prompt injection and tool safety treated as central concerns. - Kitesurf became the result: a browser available in beta through Cloudflare’s Browser Run product. ## From Prototype to Product - The project began with inspiration from Obscura, a lightweight Rust headless engine for AI automation. - Cloudflare used an AI agent to attempt a port to Workers. - The first prototype was weak, but a detailed plan and explicit success criteria allowed the agent to iterate effectively. - The promising proof of concept led the team to develop Kitesurf further. ## Testing as a Foundation - Cloudflare relied heavily on automated testing to accelerate development without sacrificing quality. - Web Platform Tests (WPT) provided standards-based criteria for implementing browser features. - Engineers curated feature assignments and sequencing so AI agents could work toward measurable goals. - Because WPT does not fully capture real-world website behavior, Cloudflare added: - Multistep Puppeteer integration tests - Comparisons against Chromium - Visual regression checks at every interaction step - This combination tested both standards conformance and practical rendering behavior. ## Rust and WebAssembly - Kitesurf uses Rust wherever possible and compiles directly to WebAssembly with `wasm-bindgen`. - This avoids the bulk and performance costs associated with Emscripten’s emulation layers and mocked dependencies. - The approach allows browser components to run closer to native performance inside Workers. ## Resilience Through Exception Handling - Since browsers must process unreliable and potentially hostile web content, failures must not terminate entire sessions. - Kitesurf follows a strict rule: - Errors degrade to a blank frame or missing element - Faults are caught at component boundaries - Safe empty defaults are used - Diagnostic information is logged - This makes individual rendering failures survivable rather than allowing malformed input to crash the browser. ## Isolation and Statelessness - Every page load is treated as untrusted input. - Sessions begin fresh, and components receive only the resources they require. - Workers provide isolation boundaries, but Kitesurf also enforces isolation within the application itself to prevent data leakage between pages. - Components are kept stateless wherever possible: - Failed components can simply be recreated - Work can be scaled horizontally and run in parallel - Burst-based workloads avoid the cost of maintaining idle instances - Recovery can consist of restarting a component and replaying a request Kitesurf’s central recommendation is to build browsers around the needs of their users—in this case, AI agents. By sacrificing human-focused features and emphasizing efficiency, structured output, isolation, resilience, and scale, Cloudflare aims to make browser automation practical for a much broader range of agentic applications.

Read original(opens in new tab)
AI AgentsCloudflare WorkersRustWebassembly+4
cloudflare3 min readCurated summary

How we’re rethinking work at Cloudflare with Cloudflare OS

Cloudflare built Cloudflare OS to let employees use AI agents safely after a sudden increase in demand for production access and automation capabilities. The company’s approach combines AI enablement with strict controls around data access, human accountability, organizational context, and engineering quality. Its experience suggests that successful AI adoption requires meeting both technical and non-technical users where they work. ## Why Cloudflare Built Cloudflare OS - Employees rapidly began using improved AI models and agent-building tools to create internal applications. - One sales employee requested production access to roughly a dozen systems and administrative deployment permissions for an AI-built “SuperApp.” - Cloudflare needed to enable experimentation without exposing internal systems, company data, or customer data. - The resulting platform combines existing products such as Workers and Access with custom services developed for internal AI workflows. ## Principles for AI Adoption - **Start with jobs to be done:** Teams should identify customer-related pain points, bottlenecks, or missed opportunities before selecting an AI tool. - **Give everyone access to AI capabilities:** AI interfaces should not be limited to developers using terminals, code editors, and repositories. - **Keep humans accountable:** Employees remain responsible for defining quality, testing outputs, and owning the workflows and agents they deploy. - **Prioritize organizational context:** Cloudflare-specific knowledge and canonical internal guidance matter more than simply choosing the most powerful model. - **Never expand permissions through AI:** AI tools and agents must inherit users’ existing access restrictions and receive only the permissions required for their tasks. Shared agents must respect each recipient’s permissions rather than the deployer’s. ## Engineering Guardrails with the Cloudflare Engineering Codex - Cloudflare created the Engineering Codex as an authoritative, opinionated guide to engineering practices. - Unlike policies, which define what engineers cannot do, the Codex describes what they should do. - Domain owners are responsible for defining quality standards across the codebase. - AI agents use the Codex throughout the software development lifecycle: - Planning work - Reviewing merge requests - Evaluating technical designs before implementation - Reviewing incident reports - Over four months, these agents identified nearly 250,000 potential issues, blocked 16,000 merges, and caught architectural problems in almost 600 designs. - Cloudflare is now focusing on helping engineers create evaluation loops for assessing the work produced by their agents. ## Rethinking AI Tools for Non-Engineers - Cloudflare initially gave non-engineering employees developer-oriented tools with more approachable interfaces. - This approach worked poorly for knowledge workers who create one-off deliverables and interact with many systems of record. - Code-focused harnesses encouraged excessive “vibe-coded” applications, often without a clear problem to solve. - Cloudflare then began working backward from users’ actual needs and introduced the idea of a “magic AI email bot” to which employees could delegate unwanted work. The supplied excerpt ends before describing how that system worked. Cloudflare’s experience recommends pairing broad AI access with strong identity, permission, context, and accountability systems. Organizations should design tools around real jobs to be done—not simply distribute coding agents—and provide interfaces suited to both engineers and non-engineers.

Read original(opens in new tab)
AI AgentsCloudflare WorkersCode ReviewZero Trust+2
cloudflare4 min readCurated summary

Cloudflare OS: an open platform for agents, apps, and work

Cloudflare OS is an open-source platform that gives every employee an agent workspace grounded in their organization’s terminology, procedures, systems, and best practices. It combines conversational agents, code execution, connected apps, workflows, and governed access to internal data. Cloudflare’s experience showed that security and resource-level authorization must be built into the platform rather than left to individual users or app developers. ## Why Organizations Need More Than Coding Agents - Code provides a clear feedback loop: it either works or fails. - Other organizational work—documents, research, processes, relationships, and physical-world outcomes—is harder for agents to support. - Agents need both: - Context about how the company operates. - Access to the systems employees use. - Cloudflare OS was created to apply agent leverage across the entire organization, not only engineering. ## Lessons from the First Version - Cloudflare’s initial system gave employees private agent workspaces. - Early limitations included: - Static apps that were not connected to live internal systems. - Repeatedly rerunning agent skills for mostly deterministic tasks, consuming additional model tokens. - Collaboration risks when users shared workspaces, apps, and outputs. - MCP servers could define which tools an agent could call, but not which underlying resources the agent had seen. - The platform therefore needed security that tracked data access and possible downstream exposure. - The new version makes security, governance, customization, and organizational context core platform features. ## Cloudflare OS Platform Components Cloudflare OS combines: - **Agent workspaces:** Browser-based environments with sessions, persistent state, files, resource access, and isolated code runtimes. - **Security and governance:** Controlled access to internal services and data. - **Personal and collaborative apps:** Modifiable applications that users can build, share, and continue evolving. - Conversations can become documents, applications, or workflows that continue operating after the initial interaction. ## Agent Workspaces for Everyone - Employees can use workspaces through a browser without being developers or using a terminal. - Company-curated skills and context prevent users from repeatedly explaining terminology, processes, and best practices to an AI model. - Shared skills allow improvements discovered by one person to benefit the wider organization. ### Research and Analysis - Agents can research using approved company context and resources. - They can write code to search, filter, join, and analyze data without loading entire datasets into the model’s context window. ### Documents, Slides, and Spreadsheets - Agents can convert research into editable documents, presentations, and spreadsheets. - Outputs can remain connected to live data, update when sources change, and be exported to services such as Google Drive. ### Connected Team Applications - When static documents are insufficient, agents can create applications with interfaces, logic, and persistent state. - These apps can use connected company resources and support collaboration among multiple users. ### Deterministic Workflows - Repetitive jobs can be implemented as workflows rather than full agent sessions. - Code handles predictable steps, while models are used only where judgment is needed. - Workflows can run manually, on schedules, or in response to events. - Access to systems of record is provided through Gatekeepers, while existing MCP servers can be connected through MCP Server Portals. ## Security and Governance - Directly distributing API keys to employees or agents creates broad, long-lived access that is difficult to constrain and audit. - MCP improves credential handling by keeping keys in servers and exposing defined tools. - Tool-level control is not sufficient: agents may combine data from multiple systems, move it to less restricted locations, or expose it through apps and generated outputs. - Authorization must therefore consider not only which tools an agent can use, but also which resources it has observed and where that information can go. ### Default-Deny Access - Cloudflare Access controls entry into Cloudflare OS. - Within the platform, every agent and app begins with no permissions. - An agent must request access to a specific resource, which can be approved or denied. - Approved resources are exposed to generated code through typed bindings such as `env.PROJECT`. - These bindings represent narrowly scoped capabilities under a specific policy. - Credentials remain isolated from both the agent and the generated code. Cloudflare OS is intended as a customizable organizational platform: companies can deploy it, connect internal systems, encode their operating knowledge as skills, and give employees governed tools for building useful apps and workflows. Its default-deny, resource-aware security model is essential for safely sharing agent-generated work across an organization.

Read original(opens in new tab)
AI AgentsModel Context ProtocolCloudflareAutomation+3
cloudflare3 min readCurated summary

WriteGuard: Fine-grained controls for MCP Servers

Cloudflare built WriteGuard to safely expand AI agents’ write access to internal MCP servers. The system centralizes authorization, risk classification, agent attribution, and auditing, addressing failures that client-side prompts or individual user vigilance cannot reliably prevent. It preserves the human user’s permissions while making each agent session identifiable and its actions queryable. ## The Risk of Uncontrolled Agent Actions - A broadly instructed cleanup agent accidentally closed thousands of tickets. - Human and agent actions were recorded under the same employee identity, making the incident difficult to investigate and repair. - Network logs could not distinguish between multiple agent sessions. - More serious failures could involve: - Amending contracts - Sending mass customer replies - Deleting database tables - Triggering destructive production actions ## MCP Fundamentals - The Model Context Protocol connects AI applications to external tools and data. - An MCP server exposes tools with: - A name - A description - An input schema - A handler that performs the operation - When an agent selects a tool, the MCP client sends the call to the server, which interacts with the downstream application. ## Cloudflare’s MCP Expansion - Cloudflare uses MCP with local clients such as OpenCode and Cloudflare OS, as well as long-running agent services. - Its internal MCP portal grew from 13 servers to 27. - Servers initially provided read-only access to systems such as Jira, GitLab, internal documentation, and operational tools. - As agents became more capable, teams requested write actions across engineering, product, design, sales, and customer success. - Cloudflare decided centralized controls were necessary because client-side skills and elicitation prompts vary across agent harnesses and can be disabled. ## WriteGuard’s Policy and Attribution Layer - WriteGuard evaluates tool configuration together with request context. - It can: - Pass a call through unchanged - Add agent attribution to supported writes - Create a scrubbed audit event - Block a call before the tool handler executes - Policies are defined per tool and include: - Risk tier - Enabled or disabled status - Labeling configuration - Risk tiers include: - **Read Only:** Search issues or inspect merge requests - **Minimal Impact:** Add reactions or mark notifications read - **Contained Write:** Add comments, create merge requests, or update issue fields - **Critical:** Merge code, deploy to production, or bulk-delete records - Labeling allows agent context to be inserted into downstream applications in formats such as plain text or HTML without modifying the MCP server. ## Preserving Human Permissions While Identifying Agents - Agents operate through the employee’s Cloudflare Access and OAuth identity. - An agent cannot perform an action its user is not authorized to perform. - Cloudflare avoided standalone agent accounts because they would create additional permissions to manage and weaken accountability. - WriteGuard supplements the human identity with MCP client and session information. - Each write can therefore be tied to both the responsible person and the specific agent session. ## Centralized, Queryable Auditing - WriteGuard classifies every invocation as successful, failed, or blocked. - It asynchronously sends scrubbed events to an internal audit Worker. - Audit records include: - MCP server and tool - Risk tier - Outcome - User and client - Request duration - Secret and sensitive input values are omitted. - Asynchronous logging avoids adding latency to the agent’s response. - MCP portal logs show raw tool invocations, while WriteGuard adds semantic classifications, agent context, and backing-service outcomes. - Central auditing makes unusually fast or widespread agent activity easier to detect and investigate. ## Recommendation Organizations expanding MCP agents beyond read-only access should use centralized, server-side policy enforcement, preserve human authorization boundaries, attach per-session agent attribution, and maintain scrubbed audit logs. Relying solely on prompts, client configuration, or undifferentiated user identities makes destructive automation difficult to prevent and even harder to understand afterward.

Read original(opens in new tab)
AI AgentsGitlabModel Context ProtocolTypeScript+4
cloudflare3 min readCurated summary

The Agent Development Lifecycle has arrived on Cloudflare

AI has made software implementation dramatically faster, exposing bottlenecks in testing, deployment, maintenance, and operations. Cloudflare argues that software development must evolve from the human-centered SDLC to an Agent Development Lifecycle (ADLC), where agents manage the full process rather than merely generate code. This requires software factories with APIs, observability, scalability, permissions, reproducibility, and self-improvement built in from the start. ## AI Has Overloaded the Traditional SDLC - The SDLC typically covers planning, design, implementation, testing, deployment, maintenance, and retirement. - AI has made implementation cheaper and faster, overwhelming downstream activities: - Open-source maintainers face huge volumes of issues and pull requests. - Production teams must handle software delivery at unprecedented speed. - Many organizations still use agents only for coding while humans perform validation, review, deployment, monitoring, and bug triage. ## From Software Teams to Software Factories - A software factory accepts inputs such as: - Production errors - Customer bug reports - Feature ideas - Agents then autonomously build, improve, deploy, and manage software. - The goal is to reduce human involvement in routine coordination and reserve human time for design, customer understanding, judgment, and creativity. - Cloudflare treats agents as customers and provides APIs that let them interact with its products and services across the SDLC. ## Requirements for Agent-Driven Development Software factories must redesign human-oriented processes so agents can operate safely and independently: - **Programmatic:** Every operation needs a reliable API; manual “ClickOps” cannot support agents. - **Horizontally scalable:** Each agent should receive isolated, production-like preview environments. - **Reproducible:** Systems must reproduce complex conditions, such as device, network, or geographic variations. - **Real-time and push-based:** Events should trigger agents instead of relying on humans to inspect dashboards. - **Atomic:** Changes must be independently testable, releasable, observable, and reversible. - **Permissioned:** Agents need controlled access and mechanisms to safely escalate permissions when necessary. - **Self-improving:** Agents must learn from prior work and operational experience. ## Cloudflare’s Initial ADLC Tools Cloudflare describes several projects intended to extend agents beyond code generation: - `@cloudflare/ci`: CI/CD infrastructure designed to operate across millions of repositories, self-heal, and spawn agents for complex tasks using Cloudflare Workflows. - OpenTelemetry traces in local development: Gives agents production-like observability through Wrangler and the Cloudflare Vite plugin. - Cloudflare Agents and Agent Traces: Provides tools for observing, maintaining, and improving agents. - AI-enforced engineering standards: Applies best practices across products, systems, and specifications. - An Astro software factory: Automatically triages, reproduces, verifies, and fixes GitHub issues to reduce the project’s issue backlog. ## Autonomous Software Requires Purpose-Built Infrastructure - Traditional SDLC tools and linear GitHub Actions workflows are designed around human decision-making and do not cover the complexity of autonomous software delivery. - Agents must handle subjective requirements, cross-functional dependencies, production risks, and operational feedback—not just run tests and open pull requests. - Like autonomous vehicles, software agents need specialized sensors, feedback systems, controls, and remote intervention capabilities rather than being placed in systems designed for humans. - The relevant standard is not whether an agent succeeds most of the time, but whether it can achieve the reliability and safety required for production. The practical recommendation is to treat agents as participants in the entire software lifecycle. Organizations adopting AI at scale should build the APIs, observability, isolation, permissions, event systems, and feedback loops needed for safe software factories—not simply add agents to existing human workflows.

Read original(opens in new tab)
AI AgentsCI/CDCloudflareGitHub Actions+3
cloudflare3 min readCurated summary

How we built a software factory to drive Astro’s GitHub issue count to zero

AI-powered software factories can address a pressing open-source problem: maintainers are overwhelmed by the flood of AI-generated issues, pull requests, and security reports. The Astro team built an automated triage pipeline that reproduces bugs, diagnoses causes, creates fixes, and ships preview releases for verification. After several months, it reduced Astro’s open issues from more than 200 to roughly 30 without mass-closing or ignoring reports. ## Building an Issue-Triage Skill - The team began by automating issue triage, one of the most time-consuming parts of open-source maintenance. - The workflow mirrors manual debugging: - **Reproduce:** Clone the reporter’s reproduction repository and confirm the problem. - **Diagnose:** Instrument the code and add logging to identify the root cause. - **Verify:** Check tests, documentation, and comments to determine whether the behavior is actually a bug. - **Fix:** Turn the reproduction into failing tests, implement a solution, and deploy it. - Each phase runs in an isolated AI subagent to reduce the tendency to force a solution. - Subagents communicate through a sequential `report.md` file containing their findings. ## Running the Pipeline in GitHub Actions - The workflow is driven by GitHub issue labels rather than a separate internal database. - New issues begin with `triage needed`; verified fixes eventually move to `fix verified`. - The pipeline reconstructs its state from labels and existing issue comments. - When a fix is ready, it: - Creates a preview release using `pkg.pr.new`. - Posts the diagnosis, logs, and installation instructions to the issue. - Lets the original reporter test the patch. - Opens a linked pull request after confirmation. ## From a Repository Workflow to Flue - The team recognized that the process was not inherently tied to GitHub. - Its core structure consists of: - An external event. - A sequence of isolated subagents. - Separate reasoning and execution permissions. - Durable workflow state. - This generalization became **Flue**, an open, platform-agnostic framework for agent workflows that can respond to GitHub events, Slack messages, cron jobs, or webhooks. ## Effects on Maintainer and Community Work - Automation did not make the Astro team less connected to users. - Instead, it freed maintainers to spend more time: - Engaging with the community in Discord. - Participating in RFCs and feature discussions. - Collaborating with contributors. - The system is designed to resolve most incoming issues, while failures are treated as signals that the codebase needs improvement. ## Using Agent Failures to Improve the Codebase Agent mistakes often reveal problems that would also challenge human developers: - **Opaque abstractions:** Component boundaries are unclear. - **Missing documentation:** Important implementation decisions are unexplained. - **Insufficient testing:** Critical behavior lacks adequate unit tests. - For example, the bot repeatedly changed an HMR-related condition and caused regressions because the logic was poorly documented and under-tested. - Adding a precise comment clarified the intended behavior, after which the bot stopped making the same incorrect change. - Fixing these weaknesses improves both future automation and human maintainability. ## Extracting the Workflow into a GitHub Action - Initially, the triage system was embedded in the Astro monorepo, making changes risky and difficult to test. - The team separated it into the standalone `triagebot-action` repository. - This enabled independent testing and safer updates to Flue and the workflow. - The action now supports Astro and has been adopted or forked by other teams building their own automated development pipelines. The practical lesson is to start with a narrow, repeatable maintenance task, isolate agent responsibilities, make all reasoning auditable, and use failures to improve documentation, architecture, and tests.

Read original(opens in new tab)
AI AgentsOpen SourceGitHub ActionsAstro+4
cloudflare3 min readCurated summary

Announcing Cloudflare Wallets: The programmable wallet for the agentic Internet

Cloudflare is introducing Wallets to help AI agents discover, test, and pay for APIs without relying on humans to handle registration, billing, and API keys. Account Wallets will fund agent-controlled Virtual Wallets with configurable spending limits, while stablecoin micropayments through the x402 protocol enable machine-native transactions. Cloudflare also proposes human-readable wallet identities so merchants can recognize agents and their sponsoring organizations. ## The Challenge of Agent Onboarding - APIs are typically designed for humans, requiring login pages, payment methods, and manual API-key generation. - Agents lack: - Stable identities for signing up. - Native payment mechanisms. - As a result, agents often abandon API evaluation and delegate onboarding back to humans, limiting agentic commerce. ## Cloudflare Wallets and x402 Payments - Users can claim a Cloudflare Wallet handle that provides a persistent username for interactions with merchants. - Wallets will support: - Storing stablecoins. - Purchasing APIs, content, and other services. - Receiving funds. - Cloudflare’s Monetization Gateway will let eligible customers sell APIs and content through the x402 protocol. - x402 attaches micropayments directly to HTTP requests, supporting uses such as AI inference, data access, and content consumption. ## Account Wallets and Virtual Wallets - **Account Wallets** - Belong to human Cloudflare account owners. - Can be funded and drained by the owner. - Delegate spending authority to agents through Virtual Wallets. - **Virtual Wallets** - Are designed for agents and accessed through API keys. - Let agents spend independently within owner-defined limits. - Can enforce allowances, merchant allow lists, and maximum transaction sizes. - This structure gives agents autonomy while preventing uncontrolled spending. ## Enabling Low-Risk Exploration - Agents can try dozens or hundreds of APIs with inexpensive x402 micropayments. - Spending caps make autonomous experimentation safer: a small budget can support many low-cost trials. - Organizations could assign policies such as a $100 weekly AI-inference budget to each employee or agent. - Agents exceeding their limits can request a human override. - Administrators can review unusual spending, raise limits, or provide one-time funding when appropriate. - Cloudflare plans to support traditional funding and withdrawals in selected regions, with stablecoin self-funding available to eligible users. ## Building a Two-Sided Agentic Market - Monetization Gateway gives merchants tools to sell resources directly to agents. - Wallets add the buyer-side infrastructure needed for agents to purchase APIs, MCP tools, and content. - Together, these systems aim to create a machine-native marketplace where agents can transact without constant human intervention. ## Persistent Agent Identity - Merchants often cannot tell which person or organization an agent represents. - This makes it difficult to provide trials, credits, or other benefits without enabling abuse through large numbers of agents. - Wallets linked to Cloudflare accounts through `cloudflare.pay` will let agents optionally identify themselves. - An identity such as `research.example.cloudflare.pay` could indicate both the agent and its associated organization. - Agents may remain unidentified, while merchants can choose whether to prioritize known identities. ## Human-Readable Identifiers - Cloudflare compares agent identity to VPN use: an unidentified agent is not necessarily malicious but may need to establish greater trust. - Existing systems such as Web Bot Auth can associate agents with cryptographic keypairs. - Cloudflare Wallet handles would make those otherwise opaque identifiers easier for humans to recognize. - The proposal intentionally avoids defining a complete identity or verification standard, focusing instead on a simple, memorable naming layer. Cloudflare’s Wallets are intended to give agents both the ability to transact and the freedom to explore services safely. Account-level controls, Virtual Wallet spending policies, and optional persistent identities could provide the foundation for a more autonomous but accountable agentic economy.

Read original(opens in new tab)
AI AgentsAgentic CommerceStablecoinsX402+4
cloudflare2 min readCurated summary

Welcome to Agents Week

The post introduces “Agents Week” by reframing the question from what an Agent Cloud should be to what agents themselves need. Unlike today’s human-oriented cloud and web, an Agent Cloud must provide agent-native primitives while also translating between existing human-designed systems and an emerging agent-shaped web. The week will explore how infrastructure, development, security, organizational access, and web interactions should evolve for agents. ## Why the Existing Cloud Falls Short - Today’s cloud and web assume a human is monitoring and interacting with them. - Interfaces are built around attention, visual dashboards, clicking, reading, and human decision-making. - Agents have different priorities: speed, structure, reliable access, and the ability to operate continuously without fatigue or distraction. ## Two Responsibilities of an Agent Cloud - Build an agent-native foundation with primitives designed for agents from the beginning rather than adapted from human tools. - Serve as a translation layer between: - The existing human-shaped web and infrastructure. - The agent-shaped systems being developed for the future. ## Topics for Agents Week The series will examine: - Storage, compute, and execution primitives required by agents. - An agentic development lifecycle, or “ADLC,” that reduces or removes humans from routine development loops. - Secure ways for employees and agents to access organizational systems of record and perform meaningful work. - The evolution of the agentic web, including discovery, access, and payments. - How humans and agents will work together during the transition to agent-oriented systems. ## Invitation to Ask Agents Directly The post encourages readers to ask their own agents what they need from an Agent Cloud instead of relying only on human assumptions. Suggested areas include cloud infrastructure, development processes, secure enterprise access, and web interactions, with readers invited to share their agents’ responses. In practical terms, designing an Agent Cloud requires starting with agents’ operational needs while supporting compatibility with the human-oriented systems that still dominate today.

Read original(opens in new tab)
AI AgentsCloud ComputingSdlcAgent Cloud+2
cloudflare3 min readCurated summary

Announcing the Monetization Gateway: charge for any resource behind Cloudflare via x402

Cloudflare is introducing the Monetization Gateway, which will let customers charge for web pages, datasets, APIs, and MCP tools protected by Cloudflare. It combines payment rules, access control, metering, and payment verification at the edge, initially using stablecoins through the x402 protocol. The goal is to make low-cost, usage-based payments practical for AI agents without requiring sellers to build billing infrastructure or onboard every buyer. ## The Web’s Shift Toward Usage-Based Payments - The traditional web monetized human attention through advertising, subscriptions, and e-commerce. - AI agents consume resources without viewing ads or maintaining subscriptions, creating a need for pricing based on actual usage. - Potential models include: - Charging a few cents per search. - Combining a base fee with usage charges, such as per megabyte uploaded. - Charging only when an outcome succeeds, such as a resolved support escalation. - Agents may generate thousands of requests and micropayments, making per-request, per-token, or outcome-based pricing more appropriate than monthly or per-seat plans. - Existing usage billing has generally required API keys, known customers, extensive accounting systems, and costly payment infrastructure. - Stablecoins such as USDC and Open USD can support sub-cent payments with low fees and settlement times under a second. ## Cloudflare’s Role in Usage-Based Billing - Cloudflare can use its position as a proxy between buyers and sellers to combine payment verification with the request path. - Metering, payment exchange, and settlement can occur away from the customer’s origin. - Customers retain control over: - Pricing. - Access rules. - Revenue. - Sellers will not need to onboard each buyer or build a complete billing system; they can define rules that determine when agents must pay. ## How x402 Payments Work - x402 uses HTTP’s `402 Payment Required` status code to add payments directly to ordinary web requests. - The flow is: - A client requests a protected resource. - The server returns a 402 response containing the price, accepted asset, and payment destination. - The client pays and retries the request with proof of payment. - A facilitator verifies the payment. - The server returns the requested resource. - There are no checkout redirects or separate payment APIs. - Payments settle peer-to-peer directly into the seller’s wallet. - x402 is well suited to machine payments because: - It supports very small transactions. - Buyers do not need an account with the seller. - The payment itself acts as the access credential. - Stablecoins offer fast settlement, low fees, and no chargebacks. ## Monetization Gateway Capabilities - Customers will define payment policies through a dedicated rules API using expressions similar to other Cloudflare rules. - The system will apply to traffic such as tokens, APIs, MCP tool calls, and datasets. - Enforcement will run across Cloudflare’s network in more than 330 cities, allowing payment handshakes to occur near buyers while reducing latency and protecting origins. - Planned functionality includes charging for specific REST methods and routes, such as requiring $0.01 for each `GET` or `POST` request to `/api/premium/*`. - The gateway is also intended to support variable pricing for tasks with different costs. Cloudflare’s approach is to make micropayments a native part of HTTP access, enabling businesses to charge agents directly for the resources they consume without constructing their own payment and accounting systems.

Read original(opens in new tab)
AI AgentsModel Context ProtocolCloudflareAPI+4
cloudflare3 min readCurated summary

Your site, your rules: new AI traffic options for all customers

Cloudflare is replacing its broad “Block AI Bots” approach with finer controls based on what automated systems do: Search, Agent, or Training. The goal is to let website owners preserve discoverability and useful automation while blocking uncompensated model training and other unwanted access. These controls will be available to all Cloudflare customers, including Free-tier users. ## Why AI traffic needs more nuance - The traditional crawler exchange—content in return for referrals—has weakened as AI systems increasingly consume content without sending traffic back. - Website owners previously faced a binary choice: - Allow AI access to remain discoverable. - Block automation and protect content at the risk of losing visibility. - This tradeoff particularly harms small sites and can favor established search providers that use the same crawlers for search and training. ## A behavior-based AI taxonomy Cloudflare will classify automated traffic by its purpose rather than simply labeling bots as “AI”: - **Search** - Collects or indexes content to answer future queries. - Builds a database proactively. - Should generally provide referrals or other fair compensation. - **Agent** - Acts in real time on behalf of a person. - Includes chat-fetch bots such as ChatGPT-User and browser-use agents driven by Gemini or Claude. - Visits a site to complete a specific task for a human. - **Training** - Collects content to train or fine-tune a model. - Permanently incorporates data into the model’s underlying architecture. Bots may have multiple classifications. Cloudflare encourages operators to separate Search, Agent, and Training crawlers so site owners can understand and control their access more effectively. ## New controls for AI traffic - Cloudflare is adding separate controls for Search, Agent, and Training traffic. - These options replace the need for a single all-or-nothing AI blocking decision. - The controls will be available to all customers, including those on the Free plan. - Cloudflare will continue tracking other automated behaviors, such as ad verification, feed fetching, and agentic transactions. ## New default rules Starting September 15, 2026: - For new domains, **Training** and **Agent** crawlers will be blocked by default on pages displaying ads. - **Search** crawlers will remain allowed by default because they are more likely to send visitors back. - The policy treats ads as an indication that human attention—and therefore monetizable traffic—is the intended outcome. - Multi-purpose crawlers will be governed by all of their classifications, using the most restrictive applicable rule. - As a result, crawlers such as Googlebot, Applebot, and BingBot may be blocked when customers choose to block Training traffic. - Website owners can opt out of the new defaults through Cloudflare Security settings before September 15. Cloudflare’s recommendation is to manage AI access by behavior: allow Search when referrals matter, permit Agents when real-time user tasks are valuable, and block Training where content reuse is not adequately compensated.

Read original(opens in new tab)
AI AgentsCloudflareBot ManagementWeb Crawlers+3
cloudflare2 min readCurated summary

Temporary Cloudflare Accounts for AI agents

Cloudflare introduced Temporary Cloudflare Accounts for AI agents, allowing them to deploy Workers without human-driven signup or authentication. With `wrangler deploy --temporary`, an agent receives a temporary account, API token, and deployment URL, then has 60 minutes to claim the account. If unclaimed, the account and its resources are automatically deleted. ## Why Frictionless Deployment Matters - Background agents often operate without a human available to complete OAuth, copy tokens, or approve MFA. - Temporary deployments support the agent’s rapid write → deploy → verify iteration cycle. - Throwaway environments let agents test code cheaply and independently. - Agent platforms increasingly need deployment workflows that work without requiring users to create accounts on unfamiliar services. ## How Temporary Accounts Work - The feature is integrated into Wrangler, Cloudflare’s CLI for creating, configuring, and deploying projects. - When an unauthenticated deployment encounters the normal signup barrier, Wrangler informs the agent about the `--temporary` option. - Running `wrangler deploy --temporary` provisions: - A temporary Cloudflare account - An API token for Wrangler - A claim URL that can be returned to the user - The temporary account can be reused for multiple deployments during the 60-minute window. ## Agent Deployment and Iteration - An agent can create a TypeScript “Hello World” Worker, deploy it, and use the returned preview URL to verify the result. - It can then modify the source and redeploy without repeating account setup. - Agents can use this loop to test and refine applications autonomously. ## Claiming or Expiring the Account - Users can open the claim link, sign up for or sign in to Cloudflare, and permanently take ownership of the temporary account. - Claiming includes associated Workers, databases, and other bindings. - Unclaimed accounts are automatically deleted after 60 minutes. ## Broader Agent Provisioning Efforts - Cloudflare is also working with Stripe on protocols for agents to create accounts, start subscriptions, register domains, and obtain deployment credentials without manual token or payment entry. - Its collaboration with WorkOS on `auth.md` aims to support agent-driven account creation through established OAuth standards. - Temporary accounts are positioned as one step toward making Cloudflare and other services easier for AI agents to use. Developers should update Wrangler and try `wrangler deploy --temporary` for autonomous, short-lived deployments, while consulting Cloudflare’s documentation for current limitations.

Read original(opens in new tab)
AI AgentsTypeScriptCloudflare WorkersStripe+4
cloudflare3 min readCurated summary

Build your own vulnerability harness

A scalable AI vulnerability program should be built around a model-agnostic harness rather than a single model, prompt, or agent session. The harness must preserve state, support resumable investigations, cross-check findings with different models, and trace issues across repositories. The authors recommend starting small with database-backed Recon, Hunt, and Validate stages, expanding only when operational bottlenecks justify it. ## Why a Harness Is Needed - Generic coding agents are poorly suited to large-scale security analysis because they: - Hold only one hypothesis at a time. - Exhaust their context windows while exploring real repositories. - Lose important information during context compaction. - Subagents help, but they do not provide the persistence, deduplication, resumability, and cross-run coordination required for security investigations. - The system should treat models as interchangeable components: - One model can discover vulnerabilities. - Another can independently validate them. - Different models expose different classes of bugs and reduce shared blind spots. - The harness, rather than any particular frontier model, is intended to be the durable investment. ## The Original Security-Audit Skill The authors began with an approximately 450-line skill designed to audit one repository in a single session. Its seven-phase workflow included: - Three parallel reconnaissance agents producing `architecture.md`. - Hunter agents attacking the code by vulnerability class. - Adversarial validators attempting to disprove findings. - A human-readable vulnerability report for surviving findings. - A schema-checked `findings.json` file. - Mechanical validation of referenced functions and line numbers. - A fresh agent independently re-verifying every finding before submission to an ingest API. This skill became the blueprint for the later pipeline: - Recon agents became the Recon stage. - Attack-class hunters became Hunt. - Adversarial reviewers became Validate. - Reports became structured findings. - Independent re-verification remained a separate validation step. ## Limitations of Single-Session Audits A single run found only about half of the bugs discovered across multiple runs, and it tended to find simpler vulnerabilities rather than subtle ones. Repeating the skill many times and manually diffing results quickly became impractical. The authors identified three major bottlenecks: - **Context exhaustion:** Long sessions cause the model to forget previously investigated bugs. The solution is to externalize state and use the model as a stateless computation engine. - **Poor persistence:** Crashes, rate limits, and connection failures can erase hours of progress if work is not stored incrementally. - **Lack of cross-repository reasoning:** Auditing one repository in isolation misses vulnerabilities at the interfaces between applications and shared components. ## Recommended Minimal Architecture The authors advise building only the infrastructure needed to address current problems: - Store Recon, Hunt, and Validate stages in a database. - Use a separate validator that cannot submit its own findings, reducing confirmation bias. - Defer cross-repository tracing until multiple important repositories need to be analyzed together. - Defer a dedicated deduplication agent until the system produces too much duplicate or low-quality output. - Begin with a well-tuned development skill, then add pipeline stages only when a specific limitation is slowing the work. ## Enterprise-Scale Direction A mature vulnerability harness should continuously scan a fleet of repositories, trace dependencies across them, and reduce thousands of raw candidates to a smaller queue of verified, actionable fixes. Frequent model interchange and independent validation are central to maintaining coverage as models change or become unavailable. The practical recommendation is to invest first in durable orchestration and state management, not allegiance to a particular model. A simple, resumable Recon–Hunt–Validate pipeline is the appropriate starting point, with cross-repository analysis and advanced deduplication added only as scale demands.

Read original(opens in new tab)
AI AgentsVulnerability ScanningSecurity AuditLlm Orchestration+3