Arcjet Agent Runtime Security Moves Control Into the AI Action Loop

Arcjet launched agent runtime security on September 17, adding live controls for AI agents after they enter production. The product targets a gap between monitoring an agent and stopping its next action. That distinction matters when agents can send messages, update databases, issue refunds, or call internal tools.

The Arcjet agent runtime security release arrives as security vendors compete to control this new execution layer. Gateways inspect traffic, identity systems authenticate actors, and observability platforms record activity. Arcjet instead wants policy checks inside the application path where an agent’s proposed action can still be blocked.

That architecture gives developers more context for each decision. It also requires them to place enforcement code around consequential actions. Arcjet’s central bet is that organizations will accept that integration work because outside controls cannot see enough application detail.

The product combines agent discovery, action-level enforcement, and audit records. Arcjet says teams can observe agents through existing telemetry, then add preventive checks through software development kits and framework integrations.

The launch is therefore not another general promise to make models safer. It is an attempt to define where responsibility begins when model output becomes a real operation.

Arcjet Agent Runtime Security Adds Three Layers of Control

Arcjet is combining visibility, prevention, and evidence within one production workflow.

The first layer is observation. Arcjet says organizations can send agent activity through OpenTelemetry, an open standard for collecting traces, metrics, and logs. Teams using Claude can also connect through Anthropic’s Compliance API.

This intake process builds an inventory of agents and applications. Arcjet then associates individual sessions with the agent that produced them. Security investigators can review a longer workflow instead of searching through disconnected prompts and tool calls.

The approach depends partly on the growing use of standardized telemetry. The OpenTelemetry project has been developing agent observability conventions for reporting agent tasks, framework activity, and model interactions.

That standardization can reduce the work required to discover agents across different frameworks. However, observation alone does not prevent an unsafe operation. It records what occurred and provides context for later analysis.

The second layer is enforcement. Arcjet places a policy decision before an agent calls a tool, database, application programming interface, or model. The application receives a typed response such as allow, block, redact, or hold for review.

A typed response is a structured result that application code can process consistently. It lets the workflow stop an action, request human approval, or return an explanation to the agent.

Arcjet also supports checks after a call. Those checks can inspect a result before another workflow step uses it. This creates controls around both the proposed action and the information returned from it.

According to the company, available policies cover prompt injection, sensitive-data exposure, automation abuse, rate limits, and resource quotas. Prompt injection occurs when untrusted content manipulates a model into following hostile or unintended instructions.

The third layer is auditing. Arcjet records the decision, policy version, actor, inputs, and related run context. That record is intended to show what an agent attempted and why the system allowed or rejected it.

The company’s corrected launch announcement describes the product through these three functions: observe, enforce, and audit. The announcement says policies can operate before and after calls involving models, tools, databases, and APIs.

This design addresses a specific operational problem. A support agent might read an email, query a customer database, and prepare a response. Each step can appear harmless when inspected alone.

The combined sequence can still expose personal information to an address added by an attacker. Arcjet attempts to preserve the earlier steps and evaluate the outgoing message within that history.

Founder and Chief Executive David Mytton told SiliconANGLE that a risky outcome can develop across several individually reasonable actions. The original launch coverage also reported integrations with several major agent frameworks.

Those integrations include the Claude Agent SDK, OpenAI Agents SDK, LangChain, Mastra, and Microsoft’s Agent Framework. Arcjet’s broader product page claims support for 20 SDKs and framework integrations.

That range matters because agent deployments rarely use one common runtime. Organizations may have web agents, queue workers, coding assistants, and scheduled workflows operating through different interfaces.

Arcjet’s product tries to connect those environments through a shared decision model. The most important change is not the inventory screen. It is the ability to place a mandatory decision before an action executes.

The Security Boundary Is Moving From Access to Action

An authenticated agent can still take the wrong action with valid credentials.

Traditional access control asks whether an identity can enter a system. That remains necessary, but it becomes incomplete when software can interpret goals and select actions autonomously.

An employee might authorize an agent to use a customer service platform. That permission does not automatically mean the agent should refund every transaction it encounters. The permitted amount, account, payment method, and surrounding request still matter.

The same problem appears in coding workflows. A coding agent may have legitimate repository access while lacking authority to expose secrets, change deployment settings, or run destructive commands.

Standing access establishes an outer boundary. It does not confirm that every action within that boundary reflects the user’s current intent.

Google described a similar shift in its 2026 Beyond Zero framework. The proposal evaluates authorization at the level of individual actions on specific resources rather than granting broad application access.

Arcjet is pursuing a narrower, deployable version of that direction. It checks the action using context available inside the application. That context can include identity, route, tool name, typed arguments, prior steps, and accumulated usage.

Consider an accounts-payable agent that can access an enterprise resource planning system. Reading an invoice and releasing payment both occur inside the same application. Their consequences differ substantially.

A network gateway may recognize traffic headed to that application. It may not understand whether the underlying function reads a supplier record or changes bank details.

An in-code check can inspect the function and its arguments. It can apply one policy to reading an invoice and another to releasing funds.

This distinction explains Arcjet’s positioning against external control planes. A gateway can centralize model routing, authentication, logging, and content checks. Arcjet argues that it loses some application context when enforcement moves outside the code taking the action.

The two approaches are not mutually exclusive. A company can use a gateway for model traffic and Arcjet for specific tool calls. The important question is which control owns the final decision.

Arcjet says local decisions add less than one millisecond of overhead. It reports between 20 and 30 milliseconds when a decision needs its cloud service.

Those figures are company claims, not independent benchmark results. They also exclude heavier checks. Arcjet says its specialist prompt-injection detection can add about 100 milliseconds before a provider call.

Latency becomes important when one agent run contains dozens of actions. A small delay can accumulate, especially when remote policy evaluation or model-based detection appears repeatedly.

The architecture therefore creates a policy-placement problem. Teams must decide which actions require local rules, remote checks, content analysis, or human review.

A read-only lookup may only require authorization and logging. A high-value refund may justify several controls and manual approval. Applying the strictest process to every action would slow workflows and increase operational friction.

Arcjet’s answer is granular enforcement. Engineering teams can keep rules near the protected handler, while security teams can manage remote policies without requesting another application deployment.

Code-based rules support testing, review, and version control. Remote rules allow security staff to adjust thresholds across services. Combining them can preserve engineering ownership while giving security teams faster intervention.

It can also introduce governance questions. An application may contain one policy while the remote service applies another. Teams need clear precedence, change history, and failure behavior.

If the cloud policy service becomes unavailable, the application must decide whether to block or continue. That decision depends on the action’s consequences and the organization’s tolerance for interruption.

The product makes the action boundary visible, but it does not eliminate these design choices. It gives teams a place to encode them.

In-Code Enforcement Challenges Gateways and Security Dashboards

The primary contest is between controls that can interrupt an action and systems that mainly observe traffic around it.

Security dashboards can identify unusual behavior after telemetry arrives. That remains useful for investigation, incident response, and compliance. It does not necessarily stop a refund or database update already completed.

AI gateways can act before a model request or response passes through them. They can detect hostile content, restrict providers, or apply spending limits at a centralized point.

However, an agent’s consequential operation may happen after the model interaction. The model proposes a tool call, and application code executes it against another system. A gateway that only sees model traffic may miss the final operation.

Arcjet places its guard inside that execution path. The application asks for a policy decision immediately before calling the relevant function. This lets the policy inspect typed arguments rather than infer intent from natural language.

A refund for a modest amount and one for a much larger amount can look similar at the network layer. The application handler knows the exact amount, account, currency, and user context.

The tradeoff is deployment scope. A centralized gateway can cover many applications once traffic is routed through it. In-code controls must be inserted at the boundaries developers identify.

Arcjet tries to reduce that burden through SDKs, hooks, and framework integrations. It also supports observation through OpenTelemetry without requiring application changes, according to the company.

Yet discovery and enforcement remain different. Telemetry can reveal an unknown agent without automatically placing a blocking control before every action that agent takes.

That distinction creates an adoption sequence. A platform team can first inventory agent activity. Developers then choose high-consequence actions and add guards around them.

The sequence is practical, but coverage can remain uneven. One service might protect refunds while another leaves account changes unguarded. Security teams need evidence showing which actions lack enforcement.

Large vendors are pursuing overlapping territory. Cisco expanded AI Defense in February 2026 with runtime protections for agent tool use and interaction governance. Its AI Defense expansion emphasizes protection across network, cloud, and on-premises environments.

Cisco’s approach benefits from an established enterprise security footprint. Arcjet’s pitch centers on application-native integration and developer adoption.

Other products focus on model firewalls, AI red teaming, identity, gateway routing, or observability. These categories increasingly overlap as vendors follow agent activity from prompts into tool execution.

Arcjet must therefore show that action-level context produces better decisions, not simply more logs. Buyers will want evidence that policies block meaningful attacks without interrupting legitimate work.

The company’s current examples are intuitive. They include refund limits, unauthorized tool calls, sensitive-data redaction, runaway loops, and dangerous action sequences.

The harder cases involve ambiguous intent. A policy can easily deny a tool unavailable to a role. It is harder to judge whether a permitted tool call matches a user’s poorly specified goal.

Deterministic policies help when organizations can express a clear rule. A deterministic policy returns the same result for the same known inputs rather than relying on open-ended model judgment.

Rules can cap spending, constrain resources, require approvals, or block specific data categories. They become less decisive when context depends on nuanced business meaning.

That limitation does not make runtime enforcement unnecessary. It defines where deterministic controls end and reasoning-based governance begins.

Arcjet’s product currently emphasizes a dependable enforcement floor. Richer sequence analysis can build on that base, but it still needs a mechanism that can stop the resulting action.

This is the strongest part of the company’s argument. Better detection offers limited protection when the application cannot enforce the decision before execution.

The weaker part is operational proof. Arcjet has not published broad third-party data showing false-positive rates, customer adoption, or incident reduction for this release.

Until those results appear, buyers must treat performance and effectiveness figures as vendor claims. Pilot deployments should run policies in observation mode before enabling blocking behavior.

Prompt Injection Is Only One Part of the Runtime Problem

A prompt filter cannot replace authorization, least privilege, budgets, or approval controls.

Prompt injection receives attention because an attacker can hide instructions inside emails, documents, websites, or tool output. An agent may treat that untrusted content as guidance and change its behavior.

Filtering can identify some hostile patterns before the content reaches a model. It cannot reliably determine whether every resulting business action is authorized.

A well-formed request may still exceed a user’s authority. A compromised account may send harmless-looking instructions. An agent can also make an error without encountering an attack.

Runtime security must therefore separate content assessment from action authorization. One check asks whether input appears hostile. Another asks whether this actor can perform this operation on this resource.

OWASP’s guidance on excessive agency recommends minimizing extensions, permissions, and autonomy. It also recommends human approval before high-impact actions.

Arcjet can supply the enforcement point for some of these controls. It cannot decide an organization’s risk tolerance or redesign an agent that holds overly broad credentials.

An agent with unnecessary database permissions remains dangerous. Blocking policies reduce exposure, but least privilege should prevent the agent from reaching many sensitive operations at all.

Human approval also needs careful implementation. A confirmation screen should display the actual tool, destination, arguments, and consequence. Asking users to approve an agent-written summary can conceal the dangerous detail.

Arcjet returns a hold-for-review decision, according to its product materials. The surrounding application still controls how that review appears and who can approve it.

Audit records create another set of concerns. Prompts and tool parameters can contain personal information, credentials, internal documents, or customer data.

Arcjet says sensitive checks can run locally while decision evidence is stored separately. It offers storage through its cloud, a single-tenant environment, a private virtual cloud, or customer-managed infrastructure.

Organizations should verify which fields leave their environment. They should also define retention, regional storage, access controls, deletion procedures, and incident-response responsibilities.

The product advertises a SOC 2 Type II report covering security, availability, and confidentiality. That assurance addresses organizational controls, but it does not validate every agent policy or integration.

Sequence-based detection introduces further uncertainty. Linking actions across sessions can reveal gradual risk that isolated checks miss. It can also produce incomplete or incorrect histories when identifiers are inconsistent.

OpenTelemetry conventions can help normalize records. They do not guarantee that every framework emits equivalent context or preserves the same identity information.

Developers must propagate correlation identifiers across queues, background jobs, and service boundaries. Missing context can make one workflow appear as several unrelated runs.

Excessive collection creates the opposite problem. Recording every prompt, tool argument, and output can expand the sensitive data available to the monitoring platform.

Security teams must balance investigative detail against data minimization. A useful audit trail should prove the decision without automatically copying every sensitive payload.

False positives present another challenge. A prompt-injection detector may flag legitimate security discussions, quoted malware instructions, or customer content.

Arcjet recommends dry-run deployment, which records decisions without enforcing them. This lets teams compare proposed blocks against real application behavior before activating a rule.

Dry runs are valuable, but they need structured review. Teams should label false positives, measure missed cases, and test failure paths rather than watching a dashboard passively.

A policy can also become stale. New tools, arguments, data classes, and business processes change the meaning of an action. Versioned policy records help investigators understand which rule applied at a given time.

They do not guarantee that the rule remained appropriate. Security and application owners must review policies as the workflow changes.

These limitations reinforce the main tradeoff. Moving enforcement into code provides useful context, but it also distributes responsibility across services and teams.

Arcjet needs to make that distributed model easier to govern than a patchwork of custom authorization checks. Otherwise, buyers may gain another policy layer without achieving consistent control.

The Next Test Is Production Evidence, Not Feature Breadth

Arcjet’s launch will matter if customers can prove coverage, low disruption, and successful intervention across real agent workflows.

The first signal to watch is adoption beyond demonstration environments. Arcjet should show how teams inventory agents, identify consequential actions, and move selected policies from dry run into enforcement.

Named production deployments would clarify which workflows buyers prioritize. Support operations, software development, finance, and internal data access present different risks and latency requirements.

The strongest evidence would include deployment time, protected-action coverage, false-positive rates, and the number of actions stopped before execution. Those measures would test Arcjet’s central claim.

The second signal is interoperability. Arcjet currently lists integrations across prominent agent frameworks and coding assistants. The market will judge whether those integrations preserve useful context across mixed environments.

Organizations rarely standardize every agent on one framework. A workflow may begin in a chat interface, continue through a queue, and finish inside a custom service.

Arcjet must connect those steps without forcing every team into one orchestration system. OpenTelemetry support provides a plausible discovery layer, while SDK guards provide enforcement.

The gap between those layers will require attention. Buyers need a clear view of discovered agents whose consequential actions remain unprotected.

Coverage reporting could become one of the product’s most valuable features. It would let security teams distinguish visibility from actual preventive control.

The third signal is competitive response. Cisco and other enterprise vendors are already adding agent interaction governance and runtime protection.

If those companies move deeper into application handlers, Arcjet’s architectural distinction will narrow. If they remain focused on centralized inspection, Arcjet can argue that its code-level context fills a persistent gap.

Agent framework providers may also add native policy hooks. That development could help Arcjet by creating common enforcement points, or reduce demand for a separate platform.

The market is likely to support layered controls. Identity, gateway inspection, action authorization, telemetry, and human review address different failure modes.

The buyer’s challenge is preventing overlap from becoming complexity. Every additional decision service creates configuration, latency, logging, and availability requirements.

Arcjet’s immediate opportunity is to become the final policy checkpoint before a consequential function runs. Its risk is becoming another dashboard that teams deploy widely but enforce narrowly.

Developers evaluating Arcjet agent runtime security should begin with one bounded workflow. They should map inputs, identities, tools, data access, approval steps, and irreversible actions.

Next, they can guard the most consequential call and operate the rule in dry-run mode. Reviewers should inspect both legitimate and adversarial cases before enabling a block.

Security teams should also test unavailable-service behavior. A refund service, production database writer, and document search tool should not share one default failure policy.

Finally, teams should verify the resulting audit evidence. An investigator must be able to reconstruct the decision without exposing unnecessary sensitive data.

The launch identifies a real shift in AI security. Agents create risk through actions, not only through model outputs. Controls must therefore follow the workflow to the point where software changes another system.

Arcjet has offered a concrete implementation of that idea. The next few months should show whether its in-code approach delivers consistent control across real organizations.

For builders, the practical question is now specific: which agent action would cause the most damage if it ran incorrectly today? Start there, verify the surrounding identity and context, then place an enforceable decision before the call.