Model Context Protocol

97 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)
github2 min readCurated summary

From coder to orchestrator: How agents shift the role of a developer

AI agents can generate impressive one-prompt demos, but reliable software delivery requires more than isolated outputs. Developers increasingly need to design workflows that define how code is proposed, tested, reviewed, and shipped. The article argues that this shifts developers from primarily writing code to orchestrating agents within controlled, repeatable systems. ## From One-Off Prompts to Reliable Workflows - A single prompt can quickly produce a demo, such as a simple game. - Production development requires repeatable delivery with: - Appropriate context - Validation and testing - Security controls - Review processes - Clear permissions and handoffs - GitHub Copilot is presented as a control plane for connecting these parts. ## An Agentic Development Flow - Familiar repository events can trigger agent work, including: - Adding a label to an issue - Running a scheduled workflow - Starting a GitHub Actions process - The agent’s changes are captured in a pull request. - Deterministic checks then validate the work through: - Linting - Tests - Security scans - Build verification - CODEOWNERS, required reviews, and branch protection rules control what can be merged. - Agents handle ambiguous, context-heavy tasks, while predictable automation provides the safety boundary. - Developers decide: - What agents can access - How tasks are scoped - Where workflows hand off - When human judgment is required ## GitHub’s Implementation Options - Copilot cloud agent workflows support event-driven automations. - Copilot CLI can run AI-powered steps inside GitHub Actions. - Model Context Protocol (MCP) can extend agents with additional tools and external context. - These options represent different stages of building an agent-enabled development workflow. ## Starting Small - Teams should begin with one bounded, low-risk workflow. - Suitable examples include: - Issue triage - Synchronizing documentation and tests - Routine maintenance updates - The recommended approach is to integrate Copilot into existing development infrastructure rather than redesigning everything at once. Developers should treat AI agents as components within an engineered delivery system, not as replacements for that system. Start with a limited workflow, surround agent output with automated checks and review controls, and gradually expand as the process proves reliable.

Read original(opens in new tab)
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)
cloudflare3 min readCurated summary

Cloudflare AI Search: give your agents a search engine for your data

Cloudflare AI Search now automates the components previously needed to build a search system, including crawling, ingestion, embeddings, vector storage, and retrieval. The update adds sitemap-free website discovery, public and custom-domain endpoints, MCP support, and integrations such as EmDash. Cloudflare is also previewing predictable pricing by including embedding and reranking costs when using select default Workers AI models. ## Easier Data Indexing - AI Search can index structured and unstructured data, including files and websites. - Website sources currently must be owned or verified through a Cloudflare zone. - The new **Discover** parsing mode crawls sites without requiring a sitemap by following links, powered by Browser Run’s `/crawl`. - A single AI Search instance can ingest, embed, and retrieve content from a website or collection of sites. ## Unified Search Across Multiple Sources - Multiple AI Search instances can be grouped into a namespace and queried together. - Users can enable public URLs to receive: - `/search` for search requests - `/mcp` for Model Context Protocol integrations - These endpoints can search across multiple websites or instances without requiring authentication. - A Worker can also bind to a namespace and perform a single multi-instance search, with results tagged and cited by source. ## Custom Domains and Access Control - Public endpoints can use custom domains such as `search.example.com/mcp`. - Cloudflare Access can be placed in front of these domains to make search private. - This supports both easily shareable public search and authenticated search for authorized users or agents. ## Pricing Model - Cloudflare is previewing a predictable, scalable pricing model for AI Search. - Embedding and reranking are included at no additional cost when using select default models from the Workers AI catalog. - Customers therefore do not need to estimate token usage for those operations. ## Cloudflare Dev Stack MCP Cloudflare uses AI Search to power its Dev Stack MCP server, which provides coding agents with current, cited documentation. - Separate instances index Cloudflare Docs, Blog, API Docs, Community, Astro, Vite, Vitest, Hono, Replicate, and OpenNext. - These sources can be combined because Cloudflare owns the underlying website data. - A Worker-based MCP server searches all relevant instances in one call. - Search results include citations and identify the originating instance. - Users can alternatively enable public namespace endpoints without writing or deploying a Worker. - The MCP server can be added to an agent with a configuration such as: ```json { "mcpServers": { "dev-stack": { "url": "https://stack.mcp.cloudflare.com/mcp" } } } ``` ## Additional Integrations - Cloudflare’s Blog, Developer Docs, and Cloudflare.com use AI Search internally. - The open-source EmDash CMS has an AI Search plugin that adds semantic search to site content. - AI Search is also used in Cloudflare’s own MCP and documentation experiences. For an existing application or MCP server, the Worker binding offers the most flexibility. For a quick, shareable search service, public `/search` and `/mcp` endpoints provide a simpler deployment path, with custom domains and Cloudflare Access available for branding and security.

Read original(opens in new tab)
cloudflare4 min readCurated summary

From ranking to recommended: get your site ready to thrive in the age of AI agents

AI assistants are becoming a major channel through which customers discover, compare, and purchase from businesses. As agents replace traditional search journeys, discoverability increasingly depends on whether a site is easy for machines to access, understand, trust, and recommend. Cloudflare’s Agent Readiness and Answer Engine Optimization (AEO) tools measure both technical accessibility and visibility in AI-generated recommendations. ## The Rise of the Agentic Audience - Fewer than half of HTML page requests reportedly come from humans, with the remainder including crawlers, bots, and increasingly capable agents. - Customers may ask AI assistants for: - Solutions to specific problems - Recommendations tailored to their needs - Comparisons between products or services - Actions performed on their behalf - Traditional metrics such as clicks and page views do not show whether AI systems can use a site or recommend it. - Agent-focused discoverability requires being found, read, and confidently cited by answer engines, shopping assistants, and research tools. ## Diagnostics: Measuring Agent Readiness Cloudflare’s Diagnostics feature evaluates a site from an agent’s perspective rather than simply loading its homepage. - It checks whether agents: - Are permitted to access the site - Can discover its content - Can retrieve clean, machine-readable content - Can identify callable interfaces and authentication methods - Diagnostic checks examine: - `robots.txt` - XML sitemaps - Response headers - Markdown content - Published metadata - APIs and agent-facing tools - Results are grouped into readiness levels from “Not Ready” to fully agent-native. - Each check returns: - Pass, fail, or neutral status - An explanation of its significance - Evidence showing the exact request and response ### Diagnostic Improvement Areas - **Quick wins:** Crawler-readable `robots.txt`, XML sitemaps, AI-crawler rules, and clean Markdown. - **Technical groundwork:** Content Signals, API catalogs, link headers, and agent login instructions. - **Advanced integration:** OAuth discovery, MCP, A2A agent cards, skills indexes, Web Bot Auth, and WebMCP. - **Commerce:** Emerging standards such as x402, ACP, UCP, and AP2. These are currently informational and do not affect the readiness score. - Recommended fixes either link directly to Cloudflare settings or generate a coding prompt that can be given to an agent. ## AEO: Measuring AI Recommendations Agent Readiness shows whether agents can access a site; AEO measures whether assistants actually recommend it. - Cloudflare infers a site’s industry and category, then tests likely customer prompts against assistants such as Claude and GPT. - Prompts cover recommendations, product comparisons, and general category advice without naming the customer’s brand. - AEO reports several visibility metrics: - **Citation Rate:** How often the site is cited as a source. - **Prominence:** How early and substantially the site appears in an answer. - **Mention Rate:** How often the brand is named, even without a source citation. - **Share of Voice:** The site’s share of citations compared with competitors. - Comparing mention and citation rates distinguishes brand awareness from authoritative attribution. ## Category Benchmarks and Industry Fit Cloudflare builds a benchmark for each industry and category before scoring individual sites. - AI assistants are queried with representative prompts to identify: - Which sites are cited - Where citations appear - How prominently each brand is represented - The benchmark is reused across accounts in the same category rather than regenerated for every scan. - This approach provides: - Instant result loading - Lower AI-compute costs - An **Industry Fit** score showing whether the site appears alongside its real competitors ## Multimodel Evaluation Because AI responses vary, Cloudflare queries assistants multiple times across different models using AI Gateway. - The system analyzes the actual answer text and cited sources customers would see. - Workers AI evaluates citation and mention patterns on Cloudflare’s infrastructure. - Exact text analysis is used alongside model-based judgment, rather than asking a model to grade its own response. - The process converts many variable responses into consistent, actionable metrics without requiring site owners to build their own evaluation framework. ## Operator Activity Cloudflare also reports real crawl and referral activity from AI operators. - Activity is shown by operator, including OpenAI and Google. - Site owners can see: - Which operators read their content - Which operators send visitors back - Errors encountered during crawling, such as `403` blocks and `404` links The broader goal is to connect controlled AEO benchmarks with real-world agent traffic, helping businesses understand both how AI systems perceive them and whether those systems can successfully access and use their sites. Businesses should treat agents as a core audience: first make the site technically accessible and machine-readable, then measure whether AI assistants cite and recommend it. Acting early may provide an advantage because most websites are not yet optimized for agent discovery.

Read original(opens in new tab)
cloudflare3 min readCurated summary

The next generation of MCP

MCP’s latest specification makes the protocol fully stateless, removing the session management and persistent connections that complicated remote deployments. Requests now carry the information they need, enabling MCP servers to run on simpler request-scoped infrastructure such as serverless Workers. The update also redesigns elicitation, improves HTTP observability, and strengthens authorization practices. ## MCP Becomes Stateless - Earlier MCP implementations required an `initialize`/`initialized` handshake and an `Mcp-Session-Id` for subsequent requests. - Stateful sessions created operational challenges: - Sticky-session routing - Open-stream management - Session migration during deployments - Reconnection problems when instances disappeared - The new protocol removes: - The mandatory handshake - `Mcp-Session-Id` - Protocol sessions from the core request path - Each request includes its protocol version, client identity, and capabilities. - `server/discover` is available for optional server inspection. - MCP servers can now execute a request and return its result without storing protocol state. - Cloudflare’s `McpAgent` is no longer required for MCP itself; developers can use `createMcpHandler` and deploy on Workers. - Durable Objects remain useful when the application—not MCP—requires state, persistence, or real-time coordination. ## Elicitation Uses Multi Round-Trip Requests - Elicitation allows servers to request additional information or approval, such as confirming a deployment or refund. - Previously, `elicitation/create` depended on an open stream, adding timeout, scaling, and infrastructure complexity. - The new Multi Round-Trip Request model works as follows: - The server returns an `input_required` result. - The client gathers the user’s response. - The client retries the operation with the requested input. - This is a breaking change from the previous approach but removes the need to preserve a transport session. ## HTTP Infrastructure Can Inspect MCP Requests - Streamable HTTP requests now include `Mcp-Method` and `Mcp-Name` headers. - Gateways, rate limiters, and web application firewalls can identify operations such as `tools/call` without parsing JSON-RPC bodies. - Operators can apply method-specific policies and collect tool-level metrics using standard HTTP infrastructure. - Results from `tools/list`, `prompts/list`, `resources/list`, and `resources/read` can include: - `ttlMs` hints - `cacheScope` hints - Deterministically ordered tool catalogs help clients reuse results and maintain stable prompt caches. ## Authorization Continues to Evolve - The specification prioritizes authorization approaches in this order: - Pre-registered clients when an established relationship exists - Client ID Metadata Documents (CIMD) for dynamic registration - Dynamic Client Registration (DCR) as a fallback - DCR is deprecated for new implementations, although the provided text ends before describing the full authorization changes. The new MCP specification significantly reduces deployment complexity by making the protocol request-oriented rather than session-oriented. Developers should migrate from `McpAgent` to `createMcpHandler` where application state is unnecessary, adopt MRTR for elicitation, and update HTTP and authorization integrations to use the new headers and registration guidance.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Give any website a WebMCP interface

Cloudflare is launching a developer preview of WebMCP that lets browser-based AI agents use websites through structured tools instead of scraping pages or navigating human-oriented interfaces. Cloudflare injects a browser-side bridge at the edge, requiring no origin-code changes or redeployment. The system currently supports tool packs such as Content Credentials and proxying an existing MCP server, with all preview tools executing in the visitor’s browser. ## Why WebMCP Matters - Traditional websites assume a human will read pages, click controls, and submit forms. - AI agents increasingly visit the web but often rely on crawlers that copy content away from the original site. - WebMCP provides a browser-native interface through `document.modelContext`. - Sites can expose tools that agents can call directly, reducing navigation overhead and token usage. - The standard is experimental in Chrome 146 and normally requires site-level implementation. ## Cloudflare’s No-Code Integration - Cloudflare adds WebMCP support through a Dashboard setting. - Enabled sites receive groups of related tools called tool packs. - New packs can be activated later without redeploying the site. - The preview includes: - A Content Credentials pack for reading C2PA metadata. - A Site MCP Server pack for exposing tools from an existing MCP server. ## Edge Injection and Browser Bridge - Cloudflare uses `HTMLRewriter` to inject a same-origin bridge script into HTML responses. - The injection leaves the site’s original HTML and application code otherwise unchanged. - The script includes: - `data-packs`, identifying enabled tool packs. - `data-mcp-url`, identifying the site’s MCP endpoint, defaulting to `/mcp`. - The bridge exits harmlessly when the browser lacks WebMCP support. - It registers tools with `document.modelContext.registerTool`. - Static packs define tools in advance, while dynamic packs discover available tools during startup. ## MCP Tools and Site Sessions - Tools use standard MCP `Tool` and `CallToolResult` types. - Existing MCP clients can interact with these browser tools without special integration. - For a site’s MCP server, the bridge: - Retrieves the server’s tool definitions through `tools/list`. - Registers browser-side proxy tools. - Sends calls to the site’s MCP endpoint using same-origin requests. - Preserves the visitor’s existing session through `credentials: "same-origin"`. - Preview tools run locally in the visitor’s browser, without requests to Cloudflare-owned services. - The edge worker architecture leaves room for future packs that use Workers AI or AI Search. ## Reading Content Credentials - The Content Credentials pack analyzes C2PA metadata embedded in images. - `scan_images_c2pa` scans images on the page and reports: - Image counts and formats. - Whether C2PA metadata exists. - Manifest counts. - Claim generators, titles, and signing organizations. - `inspect_image_c2pa` retrieves more detailed manifest data, including edit history, authorship, and certificates. - The reader examines only the metadata near the beginning of the image rather than downloading or processing the entire image. - In the current preview, credentials are reported but not cryptographically verified; results therefore indicate `signatureVerified: false`. Cloudflare’s approach makes WebMCP adoption largely configuration-driven: sites can expose agent-friendly capabilities without changing their origin code, while retaining browser execution and the visitor’s authentication context. Developers should treat it as an experimental preview, especially because browser support and credential verification are still evolving.

Read original(opens in new tab)
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)
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)
cloudflare3 min readCurated summary

Introducing the Billable Usage API: programmatic cost visibility for Cloudflare

Cloudflare is launching a Billable Usage API to make account spending accessible to automation, not just human-facing dashboards. The single endpoint reports usage and costs across products such as Workers, R2, D1, Workers AI, Vectorize, Images, and Stream. Its FOCUS-inspired schema is designed to integrate with FinOps tools, although full FOCUS conformance is still planned. ## Billable Usage API - Endpoint: - `GET /accounts/{account_id}/billable-usage` - Optional date filters: - `from=YYYY-MM-DD` - `to=YYYY-MM-DD` - Requires a Cloudflare API token with appropriate billing access. - Returns HTTP 200 with a standard Cloudflare JSON envelope: - `result` - `success` - `errors` - `messages` - Usage and cost data currently refresh daily, with more real-time reporting planned. ## Usage and Cost Data Each result row represents one product and charge period. - `ServiceName` and `ServiceFamilyName` identify the product and product family. - `ChargePeriodStart` and `ChargePeriodEnd` define the covered period. - `PricingQuantity` and `ConsumedUnit` show billable usage, such as requests, GB-months, or GB-seconds. - `ContractedCost` reports the charge in `BillingCurrency`. - `CumulatedPricingQuantity` and `CumulatedContractedCost` provide running billing-period totals. - `ZoneId` and `ZoneName` identify the relevant zone when usage is zone-specific. - Results can be filtered by date and include billing-period metadata such as `BillingPeriodStart`. ## FOCUS-Compatible Schema Cloudflare adopted naming that closely follows the FinOps Open Cost and Usage Specification (FOCUS). - Exact or near matches include: - `BillingCurrency` - `ChargePeriodStart` and `ChargePeriodEnd` - `ServiceName` - `ConsumedQuantity` and `ConsumedUnit` - `PricingQuantity` - `ContractedCost` - `ServiceFamilyName` is similar to FOCUS’s `ServiceCategory`, but uses Cloudflare’s native grouping. - `ZoneId` and `ZoneName` serve a role similar to `ResourceId` and `ResourceName`. - `CumulatedContractedCost` is a convenience field; FOCUS generally treats cumulative calculations as query-time operations. - The API is not yet fully FOCUS-compliant because some required columns are missing. ## Vantage Integration Cloudflare partnered with Vantage to bring Cloudflare costs into multi-provider FinOps workflows. - Vantage connects with a read-only Cloudflare API token granting Billing Read access. - It retrieves Billable Usage data daily and breaks spending down by: - Product - Zone - Account - Cloudflare costs appear alongside AWS, Azure, AI, and SaaS provider costs in: - Cost Reports - Budgets - Cost Alerts - Supported workflows include cross-provider allocation, anomaly detection, and FinOps-agent or MCP queries. ## Motivation for Programmatic Cost Visibility As agents increasingly deploy Workers, provision R2 buckets, and manage D1 databases, they can also create unexpected spending. Cloudflare argues that programmatic infrastructure management requires programmatic cost visibility, enabling automated monitoring, allocation, alerts, and optimization. The API is intended as a foundation for agent-driven and FinOps tooling, while Cloudflare works toward more real-time data and complete FOCUS conformance.

Read original(opens in new tab)
gitlab3 min readCurated summary

Secure every commit to production with Claude and GitLab

Claude’s security tools can identify and fix vulnerabilities during coding, but they do not govern everything that happens afterward. The post argues that GitLab should secure the remaining path to production through enforced scans, approval policies, data controls, lifecycle-wide coverage, and audit evidence. Together, Claude handles in-session authoring while GitLab provides organization-wide governance. ## From In-Session Findings to Enforced Controls - GitLab applies security configuration profiles across projects and pipelines, preventing teams from bypassing required scans. - Merge request approval policies enforce separation of duties, ensuring an agent or developer cannot approve and merge its own changes. - Critical vulnerabilities can block merges until a designated approver reviews them. - Vulnerability reports and security dashboards permanently track whether findings were detected, dismissed, or resolved. ## Turning Security Activity into Audit Evidence - Compliance controls require scans to run on every merge request and expose findings for human review. - Pipeline logs, approval records, and audit events provide reproducible evidence of what was scanned and who approved each change. - Compliance frameworks such as SOC 2, PCI DSS, and FedRAMP can map evidence to named requirements. - Compliance status reports show which controls have passed, failed, or remain pending, including activity involving agents. ## Controlling Sensitive Data Sent to Models - Context exclusions prevent secrets, proprietary files, and regulated data from being sent to AI models. - Self-managed GitLab environments and self-hosted models can keep code and inference within an organization’s boundary. - Teams can select approved models, restrict model access, and prevent code from being used for training. - GitLab Duo prompt guardrails detect secrets and limit the content available to prompts, reducing prompt-injection risk. ## Scanning Beyond the Coding Session - Session-based reviews cannot detect vulnerabilities introduced after code is written, such as newly disclosed dependency flaws like Log4Shell. - GitLab provides dependency, container, infrastructure-as-code, secret, and DAST scanning across the delivery lifecycle. - Security Review Flow uses reasoning to identify business-logic flaws, authorization errors, and race conditions that deterministic scanners may miss. - Advanced SAST produces reproducible, CWE-mapped results, providing more consistent evidence than potentially variable LLM-based findings. ## Consistent Coverage for Humans and Agents - Claude’s plugin primarily reviews code written and committed within its session. - Developer shell commands, including Claude’s `!` shell escape, may fall outside that review scope. - Claude Security can review broader codebases when explicitly invoked by a developer or administrator. - GitLab pipeline scans and merge request policies apply to every change, regardless of whether it was written by a human or an agent. GitLab’s policies and lifecycle-wide scanning provide the durable controls needed after an AI coding session ends. Teams can use Claude for immediate security feedback while relying on GitLab to enforce consistent review, protect sensitive data, block unsafe releases, and maintain audit-ready evidence through production.

Read original(opens in new tab)
line5 min readCurated summary

Analyzing Incident Causes with Natural Language in Grafana: Developing an LLM Agent-Based SRELens

SRELens is a Grafana-based natural-language observability assistant created by LY Corporation’s Home SRE team. It connects metrics, logs, traces, and profiles so engineers can investigate incidents without switching between tools or manually transferring context. The project’s central conclusion is that production reliability depends less on natural-language querying itself and more on controlling the LLM’s tools, prompts, permissions, cost, and failure behavior through backend code and policy. ## The Observability Analysis Problem - Incident investigation traditionally requires moving among: - Grafana or IMON for metrics - LaaS or IU for logs - IMON Trace or Tempo for traces - A separate profiling system - Engineers must manually connect: - Error-rate increases - Error messages - Trace IDs and slow requests - Relevant time ranges, services, and labels - This context switching is especially costly during outages. - The team first consolidated data with a self-hosted LGTM-P stack: - Mimir for metrics - Loki for logs - Tempo for traces - Pyroscope for profiles - OpenTelemetry Collector as the ingestion layer - Centralizing the data helped, but engineers still needed to know the correct datasource, labels, query syntax, and relationships between signals. ## Why an Existing Open-Source PoC Was Not Enough The team initially evaluated an open-source Grafana LLM plugin, but identified several production limitations: - It could not reliably propagate Grafana-authenticated user context for chat history, permissions, and usage limits. - System prompts could not be controlled strongly enough to enforce organizational policies. - Short tool-call limits interrupted multi-step investigations. - Datasource-specific naming differences often produced empty results: - Metrics might use `service_name` - Tempo might require `resource.service.name` - Loki might require JSON parsing or structured metadata filters - Modifying and deploying the solution internally raised operational and licensing concerns. The PoC showed that the key requirement was not merely asking questions in natural language, but retaining control over how the agent operates. ## SRELens Architecture - SRELens runs as a Grafana application plugin. - The frontend provides the chat interface. - The backend handles: - LLM requests - Tool orchestration - Prompt composition - Usage and quota enforcement - Observability queries are executed through an MCP gateway. - A `CompositeClient` combines: - Upstream FlavaMCP observability tools - Local Grafana tools such as `find_grafana_panel` and `render_grafana_panel` - The backend is an orchestration and policy layer, not just a proxy. ## Three-Layer System Prompt Design ### Base System Prompt Defines organization-wide behavior and safety rules, including: - Tool-call ordering - Safe handling of dashboard creation, modification, and deletion - Fallback behavior for empty results - Re-querying with aggregation when results are truncated - Response structure and evidence requirements Only administrators can change this layer. ### Datasource Fragment Encodes environment-specific operational knowledge in YAML: - Preferred Mimir, Loki, and Tempo datasource UIDs - Candidate service-name labels - Loki parsing and filtering rules This prevents the agent from wasting tool-call rounds discovering basic datasource conventions. ### User Prompt Stores personal or team-specific context in Redis, such as: - Owned services - Preferred response formats - Frequently used dashboards User preferences are added as context but cannot override organizational safety policies. ## Backend Tool Orchestration and Guardrails The backend exclusively assembles system prompts and runs the agent loop: 1. Send the user’s question to the LLM. 2. Execute requested MCP or local tools. 3. Return tool results to the LLM. 4. Repeat until a final answer is produced. Safety and reliability controls include: - A default maximum of 10 tool-call rounds - Duplicate-call prevention using call hashes - A default retry limit of two attempts per tool - Per-tool result-size limits - Trimming older tool results when the request history becomes too large - Preserving `tool_call_id` relationships when trimming history - Hints that encourage changing labels, time ranges, or datasources after empty results These safeguards reduce dependence on the LLM making perfect decisions. ## Usage Limits and Degraded Operation - Per-user daily token quotas - Per-user requests-per-minute limits - HTTP 429 responses after limits are exceeded - Post-response accounting based on actual prompt and completion tokens returned by OpenAI - Daily quota reset at midnight in the Asia/Seoul timezone - Redis stores conversation history, user prompts, and quotas. - If Redis is unavailable, personalization and history are reduced, but a single chat request can still proceed. ## Incident Analysis Scenario In one beta service, SRELens was asked to investigate an error spike between 09:50 and 10:05. - Instead of separately searching alerts, logs, and traces, the agent examined the relevant dashboard and observability data together. - It narrowed the incident to a surge in `CopyMedia` requests. - The analysis was intended to connect the request pattern with the underlying errors and supporting telemetry, demonstrating how SRELens can move from an aggregate error spike toward a specific API-level cause. SRELens demonstrates that an LLM can accelerate incident analysis when it is grounded in an integrated observability stack and constrained by explicit backend policies. For production use, organizations should treat prompt control, tool orchestration, permissions, quotas, retries, and failure handling as core system components rather than leaving them entirely to the model.

Read original(opens in new tab)
gitlab3 min readCurated summary

How to govern agentic AI, MCPs, and AI code assistants

Agentic AI changes software governance because agents can independently modify code, call tools, alter CI/CD configurations, and deploy without line-by-line human review. The central control model must therefore focus on agent identity, permissions, data handling, human approval points, and auditable activity. Organizations should treat agents like privileged users, with consistent policies governing what they can access, which models they may use, and when humans must intervene. ## Why Agentic AI Requires New Governance - Traditional code assistants keep humans involved in accepting or rejecting each suggestion. - Agentic systems can perform multi-step actions autonomously across the software delivery lifecycle. - Governance must answer: - What can the agent access? - What is it authorized to do? - What actions did it take, and can those actions be proven later? - Major organizational concerns include: - Distinguishing AI-generated code from human-written code. - Linking generated code to the business requirement or intent behind it. - Maintaining documentation as AI-generated code scales. - The article cites research showing widespread concern about maintainability, technical debt, and governance challenges. ## Controlling Agents, MCPs, and Tools Permissioning becomes especially important when agents use the Model Context Protocol (MCP) to connect to external tools and data. - A governance model should define: - Which agents and workflows are approved. - Where those agents may operate. - Which models they may use. - Recommended controls include: - **Central agent catalog:** Administrators publish and manage approved agents and flows. - **Composite identity:** Actions should be linked both to the agent and the human who initiated it. - **Tool approval guardrails:** Tools can run autonomously, require human approval, or be blocked. - **Prompt guardrails:** Systems should detect attempts to manipulate agents through untrusted webpages, files, or issue comments. - The objective is a role-based, auditable control plane for agents that is as consistent as existing human access management. ## Data Privacy and Self-Hosted AI Because source code is highly sensitive, organizations should establish clear data-handling policies before broad AI adoption. - Key questions include: - Whether the vendor trains models on company code. - Who owns prompts, inputs, and outputs. - Where subprocessors are located and how changes are communicated. - Self-hosted AI can keep agents and data within infrastructure controlled by the organization, which is particularly important for regulated industries. - Bring-your-own-model capabilities allow administrators to: - Use internally validated models. - Assign different models to specific agent workflows. - Reserve trusted models for sensitive operations while using managed models for lower-risk tasks. ## Defining Human Review Boundaries Governance should not eliminate autonomy; it should deliberately establish where autonomy ends. - **Interactive workflows:** Developers review and approve suggestions directly. - **Headless workflows:** Agents operate in CI/CD or other automated environments, requiring approval before sensitive actions or inspection afterward through audit trails. - Organizations should define approval requirements for: - Code review. - Testing and validation. - Deployment. - Enforcement mechanisms can include: - Merge request approval policies that apply equally to human- and agent-created changes. - Tool-level approval settings. - Scanner and pipeline controls that block changes failing security or quality checks. - An organization-wide AI governance policy is preferable to informal team-by-team practices because it promotes consistency and simplifies auditing. ## Practical Recommendation Treat agentic AI as a privileged software participant: give every agent a controlled identity, least-privilege permissions, approved model and tool access, strong privacy protections, and complete auditability. Keep human approval at security-sensitive decision points, while allowing lower-risk actions to proceed autonomously under enforced policies.

Read original(opens in new tab)
line4 min readCurated summary

Android CLI for AI Agents: Applying It to Large-Scale Mobile Development Environments

LINE’s Android app is a large monorepo with hundreds of Gradle modules and developers, making unrestricted AI-agent searches expensive and unreliable. Generic tools such as `grep` and `glob` often return excessive, semantically weak results, causing agents to waste tokens and retry. The team therefore built thin wrappers, skills, and prompts around Android CLI to provide efficient documentation lookup and Android Studio’s semantic capabilities across multiple agents. ## Why Generic Search Breaks Down at Scale - Large repositories can return huge numbers of search results from a single request. - Search output consumes agent context and increases costs. - Text search cannot reliably answer semantic questions such as: - Where a symbol is declared or used - Whether a file contains IDE-detectable problems - Whether code is unused - As the number of modules grows, agents are more likely to rely on irrelevant results and repeat searches. ## Replacing MCP Documentation Search with Android CLI - The team first adopted Android CLI for official documentation search. - It provides current documentation for Android, Jetpack Compose, AndroidX, Firebase, and related technologies. - This helps reduce hallucinations caused by outdated pretrained knowledge. - Android CLI’s `docs` commands are exposed through the `get-android-dev-knowledge` skill: - `docs search` finds relevant documentation. - `docs fetch` retrieves the document body from its Knowledge Base URL. - Compared with the previous Google Cloud Knowledge MCP setup, Android CLI eliminates: - Per-developer Google Cloud authentication - An authentication proxy - Quota-management and workaround logic - The result is fresher documentation with fewer tokens and less supporting infrastructure. ## Bundling the Android CLI Binary The team stores the Android CLI binary in the repository and invokes it from a fixed path such as `.agents/tools/android-cli/android`. - **Consistent environments** - Developers, CI systems, and agent hosts use the same pinned version. - Installation differences in version, path, and platform are reduced. - **Security enforcement** - The wrapper automatically adds `--no-metrics`. - This prevents agents from accidentally omitting the company-required telemetry setting. - A fixed binary location makes reliable wrapper enforcement possible. - **Manageable repository cost** - Existing use of Git LFS makes storing the binary relatively inexpensive. ## Handling the Android CLI Metrics Bug - Android CLI 1.0 initializes metrics tracking before honoring `--no-metrics`. - It may still attempt to write under `~/.android/cli`. - In restricted sandboxes, this causes a multi-page Java stack trace, wasting agent context. - The wrapper now probes write access before invoking the CLI: - It creates `~/.android/cli`. - It attempts to create a temporary probe file. - If writing is blocked, it emits a concise, parseable error explaining the required permission. - This converts a noisy failure into an actionable one-line message. ## Android Studio Integration Android CLI 1.0 added integration with running Android Studio instances, enabling IDE-level semantic operations from the command line. - `studio check` - Verifies that Android Studio is running. - Confirms that the target project is open and indexing is complete. - `analyze-file` - Runs IDE inspections on a single file without a build. - Detects semantic issues such as unused code. - `find-declaration` - Locates symbol declarations in the project and inside `.aar` or `.jar` dependencies. - `find-usages` - Finds references to a symbol. - `render-compose-preview` - Renders Compose `@Preview` functions as PNG images. ## Wrapping Studio Features as Skills - The team does not expose raw Android CLI behavior directly to agents. - Each capability is wrapped in a lightweight script and presented as an agent skill. - The first skill created was `studio-check`. - This follows the same design used for documentation search and ensures failures are concise, predictable, and easier for agents to interpret. ## Practical Recommendation For large Android repositories, use Android CLI behind repository-pinned wrappers and agent skills rather than exposing generic search or raw CLI commands directly. Enforce security flags, validate filesystem prerequisites early, and prefer IDE-backed semantic operations when agents need declarations, usages, inspections, or Compose previews.

Read original(opens in new tab)
gitlab3 min readCurated summary

Modernize Java with Cursor and GitLab

The post argues that modernizing Java 8 to Java 21 should be handled as a series of small, reviewable changes rather than one large AI-generated merge request. Cursor is effective for bounded coding tasks, while GitLab provides the planning, CI/CD, security, review, and lifecycle context needed to make those changes safe. The recommended approach is to begin with a focused test fix, establish quality gates, and then modernize one application boundary at a time. ## AI-Assisted Java Modernization - Java modernization affects the build, runtime, dependencies, APIs, concurrency, tests, containers, and production behavior. - A single broad prompt can produce an oversized merge request that is difficult to validate or review. - Cursor works best when given a focused issue, such as one failing test or one bounded implementation problem. - GitLab complements Cursor with: - Durable planning through epics and issue hierarchies - GitLab MCP context inside Cursor - CI/CD and security scanning - Code Review Flow and Developer Flow - Code-owner approvals and impact analysis - Cross-service testing and review evidence ## The Java HTTP Metrics Collector - The tutorial uses Tanuki IoT Platform’s Java HTTP metrics collector. - The collector: - Checks HTTP health and maintenance endpoints - Records response status and timing metrics - Sends readings to a Rust metrics-store backend through `POST /api/metrics` - This creates a realistic boundary for modernization because both the Java client and Rust backend contract must continue working. ## Project Setup and Guardrails - Required tools include Cursor, Java 8 and Java 21, Maven, Docker, Docker Compose, and GitLab MCP. - GitLab Duo Code Review Flow, Developer Flow, and an impact-analysis flow should be enabled for the project. - The repository includes `AGENTS.md`, which provides Cursor with project structure, instructions, and Maven test commands. - The workflow begins by importing the GitLab project, cloning it, and opening it in Cursor. ## Fixing the Failing End-to-End Test - The collector allows users to configure an expected HTTP status code. - The implementation incorrectly treats every 2xx response as successful and rejects configured responses such as `503`, even when they are expected. - An existing end-to-end test exposes the mismatch, but the CI job is initially allowed to fail, turning the failure into ignored background noise. - Cursor is prompted to: - Analyze the problem first - Trace the configuration through `HttpCollector` - Fix the implementation - Run the focused tests and the full Maven test suite - Once the fix passes, Cursor creates a branch and merge request. - The formerly non-blocking end-to-end job can then become a required check once it is deterministic and green. ## Review and Merge Controls - Each merge request triggers CI/CD, tests, and security scanning. - GitLab Duo Code Review evaluates the change against Java-specific project instructions. - Concrete review findings are addressed through Developer Flow before merging. - The merge request remains the central collaboration and decision point, even when Cursor performs most of the implementation work. - Fixing the test first establishes a behavioral baseline without combining it with the Java runtime migration. ## Planning the Java 21 Migration - The Java 8-to-21 migration is treated as a larger, planned effort rather than an isolated coding task. - The modernization epic contains: - Child work items - Team discussions - Research merge requests - Pipeline history - Dependencies - Security findings - This project context gives the agent information beyond the local source code and helps define the quality gates required before changing production behavior. The practical recommendation is to use Cursor for fast, narrowly scoped implementation while relying on GitLab to provide durable planning, automated evidence, and consistent review controls. This combination allows teams to modernize incrementally without sacrificing safety or reviewability.

Read original(opens in new tab)