Zero Trust Security

4 posts

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

Announcing Claude Managed Agents on Cloudflare

Cloudflare and Anthropic have integrated Claude Managed Agents with Cloudflare Sandboxes, separating Claude’s agent reasoning from the infrastructure that executes code. The integration adds customizable security controls, sandbox observability, private-service access, browser auditing, email, and custom tools. It supports both full microVMs for complex workloads and lightweight isolates for fast, large-scale execution. ## Claude Managed Agents and the “Brain vs. Hands” Model - Claude Managed Agents run on Anthropic’s platform and can: - Read and write files - Run commands and code - Browse the web - Use prompt caching, compaction, and agent-focused optimizations - The integration decouples: - **The brain:** Claude’s agent loop on Anthropic’s infrastructure - **The hands:** Code execution, tools, sandboxes, and connected services on Cloudflare - Self-managed execution gives organizations more control over security, compliance, infrastructure, and performance. ## Cloudflare-Based Agent Environments - A Workers-based control plane creates a sandbox for each Claude Agent session. - Sandboxes support: - Code execution and file operations - Application development and CLI tools - Persistent state across session sleeps - Developers can customize: - Sandbox instance sizes - Container images for VM-based sandboxes - Cloudflare provides detailed metrics and logs, dashboard monitoring, external log shipping to services such as Datadog or Splunk, and SSH access to running sandboxes. - A built-in UI helps track sandbox state and open interactive shell sessions. ## Scaling with Isolates and MicroVMs - Full microVMs are appropriate for agents that need Linux environments, developer tooling, or complete application stacks. - Cloudflare also offers lightweight V8 isolate sandboxes using Agents SDK, Dynamic Workers, and Codemode. - Isolates provide: - Millisecond-level startup - Lower infrastructure costs - File-system support and arbitrary code execution - Much higher concurrency than VM-based systems - Developers can select an “isolate” backend when configuring an agent. - Isolates are intended for workloads reaching tens of thousands of concurrent agents, while Cloudflare Containers provide microVM-based execution when stronger environment fidelity is required. ## Security and Agent Connectivity - The default deployment routes agent traffic through customizable outbound proxies. - Proxies can help: - Inject credentials outside the sandbox - Prevent agents from accessing raw secrets - Reduce data exfiltration risk - Monitor interactions with external services - Agents can connect to private internal services without exposing those services directly to the public Internet. - The integration also includes browser session controls, recordings, audit trails, and human-in-the-loop workflows. ## Built-In Agent Capabilities The deployment template includes several capabilities without requiring additional infrastructure: - Detailed sandbox metrics, logs, and SSH access - Custom sandbox images and resource sizing - Browser automation with observability - Individual email addresses and outbound email for agents - Custom tools implemented as functions and deployed directly - Flexible execution through either isolates or microVM-backed sandboxes Cloudflare’s recommendation is to use isolates for inexpensive, highly concurrent workloads and microVMs when agents require full Linux environments or complex development workflows. The integration is designed to let teams keep Claude’s reasoning on Anthropic while retaining control over execution, connectivity, security, and observability on Cloudflare.

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

Moving past bots vs. humans

The distinction between bots and humans is becoming too blurry to serve as the foundation of web protection. Browsers, accessibility tools, proxies, and AI agents can all behave differently while representing legitimate users, while human activity can also be malicious. Website owners should instead focus on intent, behavior, resource usage, and trust. ## The Web’s Original Balance - Browsers act as user agents, mediating between people and websites. - Websites rely on browser conventions to: - Present content correctly across devices. - Support purchases, logins, media, and accessibility. - Deliver advertising and control user experiences. - The web has historically balanced publisher interests with user freedoms through browser standards, extensions, and accessibility requirements. - AI agents disrupt this balance by fetching raw content without rendering pages like browsers. - Publishers often cannot tell whether a request supports one private summary or large-scale model training, making traffic and monetization less predictable. ## The Client-Server Model - Clients request resources from servers, which respond with the requested content. - Websites can scale through additional servers, caching, and CDNs. - The model’s openness allows many types of clients to interact with servers without requiring servers to understand their internal software. - That flexibility creates uncertainty: servers generally cannot see whether a response is: - Rendered for one person using a browser. - Automatically collected, archived, indexed, or reused by another system. ## Why Bot Management Exists - Websites must decide which requests they can afford to serve when capacity, CPU, or cost limits are reached. - Randomly dropping requests is possible but risks blocking legitimate users. - Access controls are also used to: - Separate attacks from normal traffic. - Manage non-malicious load. - Prevent data extraction and fake account creation. - Limit ad fraud and automated actions. - Web clients are unauthenticated by default, so services infer identity and intent from partial signals such as request volume and IP addresses. - A high-volume IP may indicate abuse, a VPN, or multiple users sharing one address, making simple bot-versus-human classifications unreliable. ## Toward Intent and Behavior-Based Protection - The important questions are whether traffic represents an attack, whether crawling is proportional to returned traffic, whether a login from a new country is expected, or whether advertisements are being manipulated. - “Bots” encompass two separate concerns: - Whether known crawlers should receive access when they provide little traffic or value in return. - Whether emerging clients behave unlike traditional browsers, affecting systems such as private rate limits. - Automation detection remains necessary, but protection systems should be designed for a future where automation is common among both legitimate and malicious actors. Website protection should evolve from identifying “bots” to evaluating intent, behavior, proportionality, and risk. The goal is not to determine whether a client is human, but whether its activity is expected, sustainable, and trustworthy.

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

Inside Figma: getting out of the (secure) shell | Figma Blog

Figma replaced its traditional bastion-host SSH model with a zero-trust shell-access system built on AWS Systems Manager Session Manager. The design combines Okta, AWS SSO, phishing-resistant WebAuthn MFA, short-lived IAM credentials, and centralized session logging. This eliminated exposed SSH ports while making access easier to manage, audit, and roll out incrementally. ## Why Figma moved beyond bastion hosts - Bastion hosts became increasingly difficult and time-consuming to secure and manage as Figma scaled. - Because bastions are critical security controls, attackers may target them to gain access to production systems and user data. - Figma’s replacement aimed to provide: - A smooth and reliable developer experience - Zero-trust networking - Strong authentication and phishing-resistant MFA - Short-lived, automatically rotating credentials - Centralized auditing and session tracing - Minimal operational maintenance - Incremental, backwards-compatible adoption ## Choosing AWS Systems Manager - Figma evaluated commercial products such as Okta Advanced Server Access. - These products lacked flexibility for existing workflows, were not always available to Figma, and could introduce external availability dependencies. - Since Figma already relied heavily on AWS, the team built a proof of concept using AWS services. - Systems Manager Session Manager provides: - Authenticated, encrypted TLS connections between users and managed instances - Interactive shells and command execution - SSH tunneling when needed - Access to EC2 and ECS without exposing SSH ports or making instances externally reachable - Centralized permission management through IAM roles ## SSO, authentication, and access control - Okta integrates with AWS SSO to provide centrally managed authentication. - Figma requires device trust and WebAuthn-based multi-factor authentication. - Authenticated users assume dedicated, minimally privileged IAM roles. - AWS access tokens are short-lived, limiting the impact of stolen credentials. - Session Manager records session transcripts in an encrypted S3 bucket for investigation and auditing. - Okta group synchronization makes access management straightforward for IT teams. - Engineers can start sessions either through the AWS Systems Manager console or through Figma’s custom command-line tool. ## Mitigating AWS SSO phishing risks - AWS SSO can be abused through device-code phishing, where attackers trick users into approving an authorization request created by the attacker. - Figma added monitoring and alerts to detect suspicious authentication activity. - Engineers are also expected to treat unexpected SSO authorization pages as suspicious. ## Setting up Session Manager - AWS provides configuration guides for both EC2 and ECS. - Figma’s approach uses Session Manager as the secure access layer while relying on IAM policies, SSO groups, and encrypted logging to control and audit sessions. - The system preserves existing workflows where necessary while removing the need for publicly accessible SSH infrastructure. Figma’s experience suggests that teams already invested in AWS can build a practical zero-trust shell-access system with native services. Session Manager, combined with strong SSO controls, least-privilege IAM, short-lived credentials, and centralized logging, offers a simpler and more secure alternative to bastion-based SSH.

Read original(opens in new tab)