cloudflareApr 13, 2026

Agents have their own computers with Sandboxes GA (opens in new tab)

Cloudflare has made Sandboxes and Cloudflare Containers generally available for running AI agents in persistent, isolated computer environments. The platform addresses the operational challenges of agent workloads—including bursty demand, fast state restoration, secure authentication, lifecycle control, and developer-friendly tooling. Recent additions make Sandboxes more capable for coding agents while reducing the cost of running them at scale. ## Why Agents Need Full Computers - Coding agents often need to clone repositories, build software, run development servers, and work across multiple languages. - Existing VM and container approaches must handle: - Rapidly creating many session-specific environments without paying for idle capacity. - Quickly restoring previous session state. - Giving agents access to services without exposing credentials. - Programmatic control over commands, files, and sandbox lifecycles. - Simple interfaces for both human developers and agents. - Figma is using Cloudflare Containers to run untrusted agent- and user-authored code for Figma Make. ## Sandboxes 101 - A Sandbox is a persistent, isolated environment powered by Cloudflare Containers. - Sandboxes are addressed by name: - Running sandboxes are reused. - Inactive sandboxes sleep automatically. - Requests wake sleeping sandboxes on demand. - The same sandbox can be accessed from anywhere using its ID. - The API supports operations such as: - `exec` for running commands. - `gitCheckout` or `gitClone` for retrieving repositories. - `writeFile` for managing files. - Command output can be streamed in real time, such as when running `npm test`. ## Secure Credential Injection - Agents may need to call private services but should not receive raw credentials. - Sandboxes inject credentials at the network layer through a programmable egress proxy. - Custom outbound rules can add authentication headers to requests based on the destination host. - This allows authenticated access while keeping secrets outside the agent’s environment. - Authentication logic can be customized for identity-aware access, dynamic rules, and Workers bindings. ## Real Terminal Access with PTY - Early agent interfaces treated shell commands as isolated request-response operations. - PTY support provides a more realistic terminal experience: - Output streams continuously. - Processes can be interrupted. - Sessions can be reconnected later. - Sandbox terminal sessions are proxied over WebSockets and are compatible with `xterm.js`. - Applications can expose the backend through `sandbox.terminal`. ## Features for Agent Development - **Persistent code interpreters:** Stateful Python, JavaScript, and TypeScript execution is available out of the box. - **Background processes:** Development servers and other long-running commands can continue running independently. - **Live preview URLs:** Agents and users can inspect development servers and verify changes while they are in progress. - **Filesystem watching:** Faster feedback as agents modify files. - **Snapshots:** Coding sessions can be quickly recovered from saved state. - **Higher limits and Active CPU Pricing:** Fleets of agents can scale without paying for unused CPU cycles. Cloudflare’s GA release positions Sandboxes as a managed environment for agent-driven software development: persistent when state matters, isolated when code is untrusted, and cost-efficient when workloads are intermittent.

authenticationcontainerscloudflare-sandboxesagent-systems+4

cloudflareApr 13, 2026

Dynamic, identity-aware, and secure Sandbox auth (opens in new tab)

Sandboxes for AI agents need more than isolation: they also require fast startup, platform control, and safe access to external services. The post introduces outbound Workers, programmable egress proxies that intercept sandbox traffic and can authenticate, restrict, modify, log, or cancel requests. This approach combines zero-trust security with identity-aware, flexible, observable, and dynamic authorization without exposing secrets to untrusted agents. ## Sandbox Requirements Sandboxes provide three core benefits: - **Security:** Untrusted users or agents can run code without compromising the host or neighboring sandboxes, often through microVM isolation. - **Speed:** Users can quickly start new sandboxes and restore existing state. - **Control:** The trusted platform can mount files, execute commands, and control network access inside the sandbox. Outbound Workers add network-level control to this model by acting as programmatic egress proxies for Sandboxes and Containers. ## How Outbound Workers Work - A sandbox can define handlers for all outbound requests or for requests to specific hosts. - For example, requests to `github.com` can be intercepted through `static outboundByHost`. - The handler can: - Add authentication headers. - Log requests. - Modify request data. - Reject or cancel requests. - Secrets remain outside the sandbox and can be accessed by the Worker through its environment. - Workers run near the sandbox, can access distributed state, and can be updated using ordinary JavaScript. A sample handler copies the request headers and injects `x-auth-token` from `env.SECRET` before forwarding the request. ## Challenges with Existing Agent Authentication Agent workloads cannot be fully trusted, even when the underlying language model is not intentionally malicious. Credentials must therefore limit accidental misuse and prevent data exfiltration. ### Standard API Tokens - Tokens are commonly passed through environment variables or mounted secret files. - They are simple to implement but expose credentials to the sandboxed workload. - A compromised or misbehaving agent could leak the token. - Expiration and rotation are required, creating operational overhead. ### Workload Identity Tokens - Systems such as OIDC provide an identity assertion rather than a general-purpose service token. - The agent can exchange the identity token for a short-lived access token. - Tokens can be invalidated when a workflow ends, simplifying expiration. - The drawback is limited upstream support: many services do not natively accept OIDC, forcing platforms to build custom token-exchange services. ### Custom Proxies - Proxies provide maximum control and can enforce granular permissions even when an upstream service has weak RBAC. - They can be combined with workload identity tokens. - However, intercepting all sandbox traffic and building an efficient, dynamic, programmable proxy is difficult. ## Characteristics of an Ideal Agent Auth System The post argues that agent authentication should be: - **Zero trust:** Never expose a reusable token to an untrusted workload. - **Simple:** Avoid complicated token minting, rotation, and decryption systems. - **Flexible:** Enforce permissions independently of the upstream service. - **Identity-aware:** Apply rules based on which sandbox is making the request. - **Observable:** Record and inspect outbound calls. - **Performant:** Avoid slow, centralized authorization round trips. - **Transparent:** Require no changes to the sandboxed application. - **Dynamic:** Allow authorization rules to change while systems are running. Outbound Workers are presented as a way to satisfy all of these requirements. ## Restriction and Observability A basic outbound handler can enforce network policy with only a few lines of JavaScript: - Inspect each outgoing HTTP request. - Log requests using disallowed methods. - Return a `405 Method Not Allowed` response for anything other than `GET`. - Forward permitted requests with `fetch(req)`. This demonstrates that outbound Workers can enforce restrictions and provide observability without modifying the application running inside the sandbox. ## Practical Recommendation Use outbound Workers as a trusted egress layer for agent sandboxes. Keep sensitive credentials outside the workload, inject or exchange them only at the proxy, and use the Worker to enforce identity-specific policies, logging, and request restrictions dynamically.

authenticationjavascriptzero-trusthttp-requests+4

gitlabMar 12, 2026

GitLab Container Virtual Registry with Docker Hardened Images (opens in new tab)

GitLab Container Virtual Registry provides a single, authenticated endpoint for pulling images from multiple registries while caching manifests and layers locally. It reduces repeated network downloads, centralizes upstream credentials, and makes it easier to adopt Docker Hardened Images without changing every team’s CI/CD configuration. The article recommends using it as an operational layer between pipelines and registries such as Docker Hub, dhi.io, MCR, and Quay.io. ## The Container Image Management Problem Platform teams often depend on several registries: - Docker Hub for common base images - dhi.io for Docker Hardened Images - MCR for .NET and Azure tooling - Quay.io for Red Hat ecosystem images - Internal registries for proprietary images This creates: - Different authentication mechanisms and image paths - Registry-specific CI/CD configuration - Repeated credential-management work - Slow builds caused by downloading identical images in every job ## How Container Virtual Registry Works - Pipelines pull through a GitLab URL such as: `gitlab.com/virtual_registries/container/<id>/image` - GitLab checks configured upstreams in priority order. - If the image is cached, GitLab serves it directly. - If not, GitLab fetches it from the appropriate upstream, caches the manifest and layers, and returns it. - Cache validity is configurable, with 24 hours presented as the default. - Developers and pipeline authors do not need to know which upstream registry provides an image. ## Benefits for Docker Hardened Images Docker Hardened Images offer: - Minimal attack surfaces - Near-zero CVEs - Software bills of materials (SBOMs) - SLSA provenance The virtual registry reduces the friction of adopting them by providing: - **Centralized authentication:** Teams authenticate to GitLab while GitLab stores and uses the dhi.io credentials. - **Simpler CI/CD:** Pipelines use one GitLab endpoint rather than configuring dhi.io separately. - **Gradual adoption:** Teams can migrate incrementally while cached image paths reveal which variants are being used. - **Improved visibility:** The cache provides an inventory of active dependencies, such as whether teams pull `library/python:3.11` instead of a hardened alternative. - **An audit trail:** Cached images help with compliance and understanding fleet-wide dependencies. ## Setting Up the Registry The article demonstrates setup with a Python client. - Create a virtual registry under a GitLab top-level group: ```python registry = client.create_virtual_registry( group_id="785414", name="platform-images", description="Cached container images for platform teams" ) ``` - Add Docker Hub as an upstream, using a 24-hour cache period. - Add dhi.io with a Docker username and access token: ```python dhi_upstream = client.create_upstream( registry_id=registry["id"], url="https://dhi.io", name="Docker Hardened Images", username="your-docker-username", password="your-docker-access-token", cache_validity_hours=24 ) ``` - Add other sources such as: - `https://mcr.microsoft.com` for Microsoft images, with a 48-hour cache period - `https://quay.io` for Quay-hosted images, with a 24-hour cache period ## Practical Recommendation Use GitLab Container Virtual Registry as a centralized pull-through cache when multiple teams rely on several container registries. Configure Docker Hardened Images as an upstream, point pipelines to the GitLab virtual registry endpoint, and use the cache contents to monitor adoption, performance, and image dependencies.

authenticationgitlabci-cdpython+4

tossMar 6, 2026

Foreign User Research: Why (opens in new tab)

Toss investigated why many foreign users struggle to use Korea’s financial services, even after signing up. Research showed that confusing identity verification, name formatting, and address entry often prevented users from completing registration, forcing them to visit bank branches for routine tasks. By redesigning the name-entry and authentication process, Toss increased the foreign-user verification completion rate by about 15% and eliminated the gap with Korean users. ## Investigating Foreign Users’ Financial Experiences - Foreigners often perceive Korea’s banking system as complex and difficult to navigate without assistance. - Toss wanted to make its “finance for everyone” vision include foreign residents. - The team suspected that several verification steps caused users to abandon registration: - Preparing a foreigner registration card - Mismatches in telecom-provider information - One-won account verification - Difficulties entering names and personal details ## Field Research with Blue-Collar Workers - The team focused especially on blue-collar foreign workers, whose financial habits were less understood than those of students or white-collar workers. - Initial attempts to arrange factory interviews failed, so researchers visited the Siheung Industrial Complex during lunch hours. - Street interviews were difficult because formal clothing, identification badges, and consent documents made passersby cautious. - A more casual approach helped the team conduct several interviews. - Researchers later visited a multicultural center in Pocheon, where they met foreign residents from different countries and with varying lengths of stay. ## Why Foreign Users Rely on Bank Branches - Mobile banking often felt like a complicated system that users could access only after repeated trial and error. - Many users abandoned the process before reaching any financial-service features. ### Name Entry and Identity Verification - Users were unsure how to format their names: - Where to place spaces - Whether to enter family names first - Whether to match their foreigner registration card, bank account, or telecom records - A name such as “BRAD PITT” might need to be entered in an unexpected format, such as “BR AD.” - Some users repeatedly failed verification because their name format differed across institutions. - One participant had never successfully completed online identity verification under their own name in eight years. - Error messages rarely explained the actual cause of failure. - After five or more failed attempts, users could no longer continue. ### Address Entry - Entering Korean addresses was another major barrier, especially for users unfamiliar with typing Korean. - Users tried postal codes, English addresses, and lot numbers, then searched through address lists. - Search results often displayed too many options, making the correct address difficult to locate. - Repeated unsuccessful searches led some users to abandon registration and visit an offline branch instead. ## Improving the Authentication Funnel - Research identified name entry and authentication as the primary causes of foreign-user drop-off. - Toss’s product team redesigned the name-input structure and authentication flow. - The changes increased the foreign-user authentication completion rate by approximately 15%. - The completion-rate gap between Korean and foreign users was ultimately eliminated. Toss’s research demonstrates that inclusive financial services require understanding users who are often overlooked. Removing small but fundamental barriers in registration and authentication can make digital banking accessible to a much broader population.

authenticationdatabase-designuxuser-research+4

gitlabJan 27, 2026

How to set up GitLab SAML SSO with Google Workspace (opens in new tab)

Organizations using GitLab.com SaaS can streamline access control by integrating SAML-based Single Sign-On (SSO) with Google Workspace. This setup enables automated user provisioning and dynamic permission management by mapping Google Workspace groups directly to GitLab roles. The result is a centralized security model that reduces manual administrative tasks while ensuring users have immediate, secure access to the platform. ### Prerequisites and Architectural Benefits * The integration requires a GitLab Premium or Ultimate subscription and Super Admin access to Google Workspace. * Once configured, the authentication flow redirects users to Google for credentials, after which Google sends a SAML assertion to GitLab containing user details and group memberships. * The system supports "Just-in-Time" provisioning, meaning GitLab accounts are created automatically upon a user's first successful login. * Permissions are dynamic; GitLab updates group memberships and roles every time a user signs in to reflect their current status in Google Workspace. ### Gathering GitLab Configuration Details * Configuration must be performed at the GitLab top-level group rather than within individual subgroups. * Administrators need to retrieve the Assertion Consumer Service (ACS) URL, which typically follows the format `https://gitlab.com/groups/[your-group]/-/saml/callback`. * The Identifier (Entity ID) must be copied to uniquely identify the GitLab group within the Google identity provider settings. * The GitLab SSO URL is the specific entry point users will utilize to initiate the authentication process. ### Configuring the Google Workspace SAML Application * Within the Google Admin Console, administrators must create a "Custom SAML app" to house the integration settings. * The setup process provides a Google SSO URL and a certificate file (typically a `.pem` format) that must be saved for the GitLab-side configuration. * The previously gathered GitLab ACS URL and Entity ID are entered into the Service Provider details section of the Google app configuration. ### Mapping User Attributes and Synchronizing Groups * Specific attribute mapping is required to ensure user data flows correctly: Google’s "Primary Email" should map to the "NameID," "First Name" to "firstName," and "Last Name" to "lastName." * For group synchronization to function, administrators must map selected Google Groups to an app attribute named exactly `groups` (lowercase). * Google allows for the synchronization of up to 75 groups, which GitLab uses to determine and update user permissions upon login. * The application must be explicitly turned "ON" for specific organizational units or the entire domain within the Google Admin Console to allow user access. ### Finalizing the Identity Provider Connection * GitLab requires a SHA-1 certificate fingerprint for security verification rather than the raw certificate file provided by Google. * Administrators must convert the downloaded Google `.pem` certificate into a SHA-1 fingerprint using an online conversion tool or a command-line utility. * This fingerprint, along with the Google SSO URL, is entered into GitLab’s SAML SSO settings to establish the trusted connection between the two platforms. To ensure a smooth rollout, it is recommended to test the integration with a small group of users before enforcing SAML for the entire organization. This allows administrators to verify that group-based permissions are mapping correctly to GitLab roles without disrupting existing workflows.

authenticationgitlabsecuritygoogle-workspace+3