Fastly AI Firewall Launches With Runtime Controls, but Edge Security Is the Real Test

Fastly launched three connected AI controls on September 21, including Fastly AI Firewall, AI Runtime Control, and expanded API Security. The combined release puts model routing, prompt inspection, spending limits, and agent restrictions into Fastly's existing edge request path.

That positioning creates the central tension. Fastly is not selling another isolated model filter. It wants customers to make its infrastructure the control point between applications, AI providers, users, and enterprise APIs.

Cloudflare and Palo Alto Networks already compete for parts of that position. Fastly must therefore prove that its edge architecture provides useful control without adding unacceptable latency, cost, privacy exposure, or deployment complexity.

The launch arrives as machine traffic occupies more of Fastly's network. Fastly says machine-generated requests exceeded half of network traffic during July and August 2026. It also says AI traffic grew 6.5 times faster than human traffic from January through May.

Those figures come from Fastly's own network observations, not an independent measurement of the wider internet. Still, they explain why an edge provider sees AI governance as an infrastructure opportunity rather than a separate security category.

Fastly AI Firewall Turns the Edge Into an AI Control Point

Fastly's release combines three controls that address different parts of a production AI request.

AI Runtime Control sits between an application and its model providers. Applications send model requests through one Fastly endpoint instead of calling each provider directly.

Fastly uses virtual keys to shield the underlying provider credentials. Administrators can associate those keys with models, users, budgets, and traffic limits while retaining access to public or self-hosted providers.

This architecture gives operators a central view of request volume, token consumption, provider selection, and model responses. It also supports provider failover when a configured service becomes unavailable.

Fastly AI Firewall adds security inspection to that control plane. It checks prompts before forwarding them and examines eligible responses before returning them to an application.

The company says the firewall looks for known prompt-injection and jailbreak patterns. Prompt injection occurs when untrusted input attempts to replace or override instructions that should govern a model.

Customers can run the firewall in logging mode or blocking mode. Logging preserves the request while recording a detection, while blocking rejects a matching request before it reaches the provider.

The third component addresses agents that call enterprise APIs. Fastly's expanded API Security can compare incoming requests with a published API contract, which defines the operations and data formats a service accepts.

Organizations can observe or block requests that violate those contracts. The control applies to conventional applications, assisted workflows, and autonomous agents.

That distinction matters because an agent can produce syntactically valid network traffic while attempting an unsupported operation. A traditional availability check does not determine whether the requested action belongs within the agent's authority.

Fastly presents the three components as one request-path system. Model calls can be routed and measured, prompts can be inspected, and agent actions can be limited at an API boundary.

According to the launch announcement, all three capabilities became available when Fastly announced them. The release did not describe a future preview or an invitation-only research project.

Fastly also says the controls run on its existing global platform. That network had 622 terabits per second of capacity as of June 30, 2026, according to the company.

It handled more than five trillion requests per day as of March 31, Fastly says. Those numbers describe platform scale, but they do not establish the performance of the new AI products.

The strategic change is still clear. Fastly has extended its delivery and application-security position into the model request path, where AI spending and security policies can be enforced together.

That creates a broader sales proposition than a standalone prompt filter. It also asks customers to place sensitive model interactions inside another operational layer.

Why AI Runtime Control Is Becoming an Infrastructure Contest

Enterprise AI creates a routing problem, a cost problem, and an authorization problem at the same time.

An early AI application often connects directly to one model provider with one credential. Production systems are more complicated because teams use multiple models, accounts, regions, and failover paths.

Agents expand that complexity. They can select tools, send requests, retrieve data, and trigger operations without a person approving every network call.

Fastly AI Runtime Control attempts to standardize those interactions before they reach a provider. A virtual key identifies the caller while Fastly substitutes the actual provider credential later in the request path.

That can reduce the spread of provider keys across applications and developer environments. It also gives an organization a consistent place to apply rate and budget policies.

Fastly's runtime documentation says rate limits can operate on requests or tokens per minute. Budget rules can alert administrators or block additional activity after a configured threshold.

Token-based enforcement has an important qualification. Fastly states that final token counts remain unknown until the response completes, so token limits operate on a best-effort basis.

This means the control plane can constrain usage without guaranteeing perfectly exact token enforcement. A costly response can complete before its final token count enters the accounting record.

The same documentation says administrators can inspect request and response records. Logs can include model names, virtual keys, session data, timestamps, and token counts.

That visibility offers operational value, but it creates a governance question. Prompts and completions can contain internal documents, customer data, credentials, or personal information.

Security teams will need clear retention, access-control, and regional-processing policies before centralizing those records. A unified log is useful only when the organization also governs who can inspect it.

Fastly's decision to combine traffic management with security reflects a larger market shift. AI gateways are becoming policy enforcement points rather than simple proxies.

Cloudflare, for example, combines AI Gateway monitoring with application-security controls on its network. Its prompt-injection controls assign requests a score that customers can use in firewall or rate-limiting rules.

Palo Alto Networks approaches the issue from enterprise security. Its runtime security inspects live interactions among models, applications, agents, plugins, data, and external services.

These products do not have identical architectures or coverage. However, they compete for the same valuable location: the point where an AI interaction can still be observed and stopped.

Fastly's advantage is its existing role in delivering and protecting application traffic. Customers already using its edge network may prefer extending an established control plane over deploying another independent gateway.

Its disadvantage is equally direct. Buyers can select a cloud platform, security vendor, or specialist gateway that already sits closer to their models, identities, or data controls.

This contest pressures both infrastructure providers and enterprise buyers. Providers must connect performance, security, observability, and cost governance without producing conflicting policy systems.

Buyers must decide where authority belongs. The network edge offers broad visibility, while application code can preserve more detailed business context.

No single layer sees everything. A gateway can inspect a request, but the application may know whether the requested action is appropriate for a particular customer or workflow.

Fastly is betting that the edge can become the common enforcement layer while applications retain their own authorization logic. The value of AI Runtime Control depends on how well those two layers cooperate.

The Product's Mechanism Also Defines Its Limits

Fastly AI Firewall reduces exposure in the request path, but it does not eliminate prompt injection or unsafe agent behavior.

Fastly describes its inspection as deterministic. The firewall checks requests against known injection and jailbreak signatures rather than sending every prompt through another generative model.

That choice has practical appeal. Deterministic checks can offer predictable behavior and avoid the expense of running a second model for every interaction.

Fastly also wraps untrusted input with cryptographic boundary tokens. The accompanying instructions tell the model to treat the wrapped material as data, not as authoritative commands.

This technique addresses a basic weakness in language-model applications. System instructions and untrusted text ultimately reach a model as related streams of tokens, despite their different intended authority.

A malicious document can therefore contain instructions aimed at the model reading it. The attack becomes indirect when the payload enters through retrieved content, email, a website, or another external source.

Fastly checks eligible output for evidence that an attack affected the model. Administrators can review detection tags, threat classifications, and canary results alongside other request information.

These controls add friction for known attacks, but attackers can vary wording, encoding, language, or context. A signature system must keep changing as new evasion methods appear.

OWASP ranks prompt injection first in its 2025 list of major risks for large-language-model applications. Its prevention guidance recommends layered defenses instead of relying on one filter.

Those defenses include separating instructions from data, limiting model privileges, validating outputs, requiring human approval for important actions, and monitoring behavior.

Fastly's documentation exposes another boundary. Response inspection requires a complete response, so streaming requests pass through without output inspection.

Streaming delivers generated text incrementally instead of waiting for the full answer. It supports responsive chat interfaces, but the firewall cannot evaluate the completed response before the application begins receiving it.

Structural isolation also adds tokens to requests. Fastly states that customers' model providers bill those additional tokens under their ordinary usage.

That does not make the protection impractical. It does mean customers must measure whether the extra token cost remains acceptable at their production volume.

Latency requires similar scrutiny. Inline inspection adds processing to a path where users already wait for model inference, tool execution, and data retrieval.

Fastly's edge footprint should reduce network distance for many requests. The announcement does not provide independent latency benchmarks for the complete firewall and control-plane sequence.

False positives present a separate tradeoff. Security-related discussions, debugging prompts, and research content can legitimately include the same phrases that appear in an attack.

Logging mode lets teams observe those detections before blocking. It also leaves matching requests active during the evaluation period.

Blocking mode reduces that exposure but risks rejecting valid traffic. Customers will need workload-specific testing rather than treating one policy as suitable for every application.

The API enforcement component also depends on accurate contracts. An outdated or incomplete schema can block valid agent activity or permit operations whose risk appears only in business context.

Contract compliance is not the same as authorization. An agent may call an allowed endpoint with valid data while pursuing an inappropriate objective.

The product therefore works best as one layer in a broader system. Application permissions, identity controls, tool restrictions, audit logs, and human approval remain necessary.

The launch is significant because it packages these controls inside existing infrastructure. Its importance should not be confused with a claim that network inspection solves the full agent-security problem.

Fastly Faces Cloudflare and Security Vendors for the Same Request Path

The main competitive battle concerns control of AI traffic, not ownership of the underlying model.

Fastly does not need customers to standardize on one model provider. AI Runtime Control is designed to route requests across public and self-hosted models through a common endpoint.

Provider independence can appeal to teams concerned about outages, changing model performance, or dependence on one vendor. It also creates a central intermediary that customers must operate and trust.

Cloudflare follows a related edge strategy. Its AI Gateway handles model observability and control, while AI Security for Apps adds prompt, topic, and data-related detections through its web application firewall.

Cloudflare's published injection system uses a graded score from 1 to 99. Fastly emphasizes deterministic signatures, boundary tokens, detection tags, and customer-selected log or block behavior.

The available documentation describes different control surfaces, but it does not support a definitive accuracy comparison. Independent tests would need common datasets, configurations, models, and attack methods.

Palo Alto Networks offers a wider security framing. Its runtime product describes protections for injection, poisoned content, malicious links, data leakage, model interactions, and agent activity.

That breadth can suit organizations already standardizing security operations on Palo Alto Networks. Fastly can counter with proximity to application delivery and an architecture familiar to its existing customers.

Specialist AI-security companies create another source of pressure. They can focus narrowly on model evaluation, red teaming, guardrails, or agent behavior without maintaining a general delivery network.

Specialists may innovate quickly within one threat category. They can also force customers to add another vendor, proxy, policy language, and telemetry store.

The buying decision will therefore depend on more than a feature checklist. Teams must compare deployment location, data handling, model coverage, policy expressiveness, observability, and failure behavior.

Failure behavior deserves particular attention. An inline control must decide whether traffic continues when inspection, logging, or policy services become unavailable.

Fail-open behavior protects availability but allows uninspected traffic. Fail-closed behavior preserves enforcement but can turn a security dependency into an application outage.

Fastly highlights provider failover inside AI Runtime Control. Buyers should separately verify how the platform handles failures in firewall inspection, logging, policy evaluation, and API validation.

Vendor consolidation creates its own tension. Using one platform for delivery, application security, AI routing, and agent controls can reduce operational fragmentation.

It can also increase dependency on one request path. A configuration mistake, platform incident, or account compromise could affect several layers simultaneously.

Organizations with strict isolation requirements may prefer separate providers or enforcement points. Others will accept concentration in exchange for simpler operations and unified telemetry.

Fastly must also prove that existing edge customers want the company to manage model interactions. Delivering web assets and inspecting full AI conversations create different privacy and compliance expectations.

The strongest near-term adoption path probably runs through current Fastly customers. They already send application traffic through the network and understand its configuration model.

New customers have a harder comparison. Fastly must show enough security depth to compete with dedicated vendors and enough operational value to justify rerouting model calls.

This is why the release is more than a feature announcement. Fastly is trying to expand from protecting applications into governing the AI activity those applications generate.

Three Signals Will Show Whether Fastly's AI Security Bet Works

Adoption evidence, independent security testing, and competitive responses will reveal whether the edge becomes a durable AI control layer.

The first signal is production adoption. Fastly should eventually disclose customer examples that explain which models, workloads, and policies run through AI Runtime Control.

Useful case studies would report deployment scope, migration effort, blocked activity, false-positive handling, and operational outcomes. General statements about visibility or security would provide less evidence.

Customers should also describe how they govern prompt and completion logs. That information will show whether centralized observability survives privacy, compliance, and internal-access reviews.

The second signal is independent evaluation of Fastly AI Firewall. Tests should measure detection rates across direct injection, indirect injection, jailbreaks, encoded prompts, multilingual attacks, and benign security content.

They should also publish false-positive rates, latency, added token consumption, and behavior under streaming. Without those measurements, buyers can compare architecture but not verified defensive performance.

Testing must account for changing models and attack methods. A control that performs well against known signatures can still struggle with adaptive or application-specific attacks.

The third signal is how Cloudflare, Palo Alto Networks, and specialist vendors respond. More integrated routing, identity, data-loss prevention, or agent authorization would increase pressure on Fastly's combined platform.

Fastly's own roadmap will matter too. The current documentation already identifies practical limits, including best-effort token enforcement and incomplete inspection for streamed responses.

Closing those gaps would strengthen the case for one control plane. Leaving them unchanged would preserve room for application-level or competing security layers.

Enterprise teams do not need to wait for the market to settle before evaluating the release. They can begin with a narrow workload in logging mode and compare detections against their existing controls.

A pilot should include representative benign prompts, adversarial tests, streamed responses, provider failures, and budget-limit scenarios. Teams should also verify what Fastly stores and who can access each record.

Agent trials need an additional test. An agent should face explicit tool permissions and API contracts while attempting both valid and unauthorized workflows.

The result should be measured at the business-action level, not only the network-request level. A well-formed request can still produce an unacceptable action.

Fastly AI Firewall deserves attention because it connects security with routing, spending, and agent API enforcement. That combination matches the operational shape of production AI more closely than an isolated prompt filter.

The open question is whether Fastly can turn its position on the network into reliable authority over AI behavior. Edge inspection supplies visibility and an enforcement opportunity, but business context still lives elsewhere.

For developers and security leaders, the next move is concrete: test the Fastly AI controls against real workloads, document every blind spot, and compare the results with competing request-path defenses. The product's value will emerge from measured behavior under failure and attack, not from the size of the network beneath it.