api-calls

2 posts

cloudflare

Welcome to Agents Week (opens in new tab)

Cloudflare argues that AI agents require a fundamental shift in Internet and cloud infrastructure. Unlike traditional one-to-many applications, agents create unique, ephemeral execution environments for individual users and tasks, making current container-based economics and scaling inadequate. The company positions lightweight V8 isolates, alongside containers and browser support, as the foundation for making agents practical at global scale. ## The Internet Was Built for Applications, Not Agents - Cloud infrastructure evolved during the smartphone era to serve many users through a finite number of application instances. - Microservices, containers, Kubernetes, load balancing, and replication all support this one-to-many model. - Agents differ because an LLM dynamically determines code paths, tool usage, and task duration. ## One User, One Agent, One Task - Each agent may need its own execution environment, filesystem, tools, and state. - Coding agents currently use containers with access to Git, Bash, filesystems, and arbitrary binaries. - As agents spread to assistants, analysts, customer service, and planning tasks, the number of simultaneous environments could grow dramatically. ## The Scale Challenge - If 100 million US knowledge workers used agents at 15% concurrency, infrastructure would need about 24 million simultaneous sessions. - At 25–50 users per CPU, that implies roughly 500,000 to 1 million server CPUs in the US alone. - Multiple agents per person and global adoption would increase demand by orders of magnitude. ## Isolates as Agent Infrastructure - Cloudflare’s Workers platform uses V8 isolates instead of containers. - Isolates start in milliseconds, use only a few megabytes of memory, and provide secure sandboxing. - They can be up to 100 times faster to start and up to 100 times more memory-efficient than containers. - Dynamic Workers can create execution environments on demand, run code, and discard them at a scale of millions per second. - This efficiency could make one-agent-per-user economics viable beyond expensive coding assistants. ## The “Horseless Carriage” Phase - Early agent infrastructure often adapts existing systems instead of using designs built specifically for agents. - Agents use headless browsers to navigate human-oriented websites, though structured protocols such as MCP could provide direct service access. - Many MCP servers simply wrap REST APIs, despite LLMs often being better at writing and executing code than making long sequences of tool calls. - CAPTCHAs and behavioral fingerprinting ask whether a requester is human, while agent systems need identity, authorization, and permission controls. - Full containers are frequently used for tasks that require only a few API calls and a response. ## Supporting Both Old and New Models - Infrastructure transitions rarely happen all at once; technologies such as IPv4/IPv6, HTTP/2/HTTP/3, and TLS 1.2/1.3 coexist. - Cloudflare plans to support existing agent workloads while developing more efficient primitives. - Containers remain important for coding agents that need filesystems, Git, Bash, and arbitrary binaries. - Cloudflare is also expanding container-based sandbox environments and browser-rendering capabilities for services that do not yet support agent-native protocols. Cloudflare’s broader recommendation is to build infrastructure that can serve today’s container-based agents while moving toward lightweight, ephemeral isolates designed for billions of specialized agent sessions.

aws

Amazon Bedrock Guardrails supports cross-account safeguards with centralized control and management | Amazon Web Services (opens in new tab)

Amazon Bedrock Guardrails now supports cross-account safeguards, allowing organizations to centrally enforce safety controls across AWS accounts and organizational units. Administrators can apply immutable, versioned guardrails to all Bedrock model invocations while still allowing account- or application-specific policies. The capability is generally available across commercial and GovCloud Regions where Bedrock Guardrails is supported. ## Centralized Organization- and Account-Level Enforcement - **Organization-level enforcement** uses an Amazon Bedrock policy created in the AWS Organizations management account. - Policies can attach a specified guardrail and version to: - The organization root - Organizational units - Individual AWS accounts - The selected guardrail is automatically applied to Bedrock inference requests across targeted member entities. - Different policies and guardrails can be assigned to different accounts or organizational units. - **Account-level enforcement** applies a configured guardrail to all Bedrock inference API calls within one account and Region. ## Configuring Guardrail Coverage - Guardrails must use a specific version so their configuration remains immutable and cannot be changed by member accounts. - Administrators can choose whether enforcement: - Includes or excludes specific Bedrock models - Covers all or only selected system and user prompt content - **Comprehensive** mode guards all content, regardless of caller-provided tags. - **Selective** mode relies on callers to identify content requiring protection, reducing processing for pre-validated inputs. ## Testing and Verification - Account-level enforcement can be configured in the Amazon Bedrock Guardrails console. - Enforcement can be tested with: - `InvokeModel` - `InvokeModelWithResponseStream` - `Converse` - `ConverseStream` - Responses include guardrail assessment details and identify the enforced guardrail. - Member accounts can verify organization-level enforcement in the Bedrock console. ## Important Considerations - Organizations must meet prerequisites such as configuring resource-based policies for guardrails. - Incorrect or invalid guardrail ARNs can cause policy violations, prevent safeguards from being enforced, and block model inference. - Automated Reasoning checks are not supported. - Charges apply for each enforced guardrail based on its configured safeguards. ## Availability Cross-account safeguards are generally available in all commercial and GovCloud AWS Regions where Amazon Bedrock Guardrails is available. Organizations can enable the feature through the Amazon Bedrock and AWS Organizations consoles. Overall, the capability gives security teams a centralized way to enforce responsible AI requirements while reducing the need to audit guardrail settings independently in every account and application.