Arcjet agent security: from observation to enforcement

An agent can appear in an observability dashboard, have an authenticated identity and still modify a record it should not touch. For a CTO, the agent security question is concrete: which component can prevent the external effect, using what information, and what happens if that component fails? A later record helps an investigation; the ability to block must exist before the write.

On September 17, 2026, Arcjet announced the availability of Agent Runtime Security, organized around observation, enforcement and auditing. The announcement includes activity ingestion through OpenTelemetry. The novelty needs qualification: Arcjet Guards had already been announced on April 30. This launch expands the product proposition; it does not introduce the concept of controlling tools.

The adoption decision we propose is to evaluate six criteria before expanding permissions. The following analysis combines vendor documentation with Wasyra architecture recommendations. It is neither a performance test nor a product certification, and it does not assume that installing an SDK closes every execution path.

Arcjet documentation distinguishes events imported through OpenTelemetry or the Compliance API from points that can reject a call. The former provide context; intervention requires a guard or hook. That distinction changes how to read a dashboard: a visible action without an associated decision can reveal an uncontrolled path. Also, a received export does not mean the event is already queryable.

Build an inventory by business operation: changing an address, attaching a document, exporting information or changing status. For each, identify its actual entry points: chat, scheduled task, queue and internal endpoint. As a proposed criterion, require every consequential path to have an owner and a blocking test. Counting observed sessions does not prove that coverage; comparing the inventory with recorded decisions helps uncover gaps.

Arcjet receives the actor asserted by the application; it does not authenticate it. Its contract requires deriving it from authenticated server state. If the model also supplies role, tenant or permitted resources, it can end up constructing its own authorization.

Separate proposals from facts. The agent proposes an identifier and a change; the server resolves resource ownership, permissions and current state. Validate format and type, but also provenance and scope. Our recommendation is to document each input with its source and owner. A syntactically valid identifier belonging to another organization must be rejected before it becomes policy context.

In the documented mechanism, the guard sits before the action and the application remains responsible for enforcing the decision. Rego expresses conditions over an input document; it does not make those inputs trustworthy by itself. Arcjet constrains that evaluation profile: an expression does not query the network or a clock. The application must provide the necessary context.

Hypothetical example: a support agent requests a delivery-address change for an order. The server checks the customer, loads the order and verifies that it has not shipped. If its state changes after policy evaluation, an earlier authorization is insufficient. We recommend that the write also check the expected order version, using a transaction or conditional update. If it does not match, reload and reevaluate; do not reuse the earlier permission.

Arcjet reference documents an important difference: the direct Guard client can return ALLOW with an error result when evaluation cannot complete. Framework wrappers block by default on denial or unavailable evaluation. A direct integration therefore also needs to inspect hasFailedOpen(); checking ALLOW alone does not establish that the policy ran.

For the address change in our example, we propose stopping the write if evaluation is incomplete and offering operational review. For a public lookup, a team might accept a different availability policy. Decide per action, record the reason and avoid turning a network outage into implicit permission. Test lost connectivity, timeouts and an incorrectly initialized client in a controlled environment, using the same adapter that will be deployed.

In Arcjet, LOCAL/SERVER indicates where a value is evaluated and whether its original content is transmitted. It does not classify trust. Documentation warns that a local digest is not anonymization. We recommend reviewing the entire data path: tool, detector, exporter and storage.

As a proposed minimum record for our example, retain the operation identifier, internal identity, resource, evaluated version, policy revision, decision and actual write outcome. Avoid copying the full address into every event. An allowed decision and a completed modification are different facts; linking them helps investigate an authorized operation that later failed. Define retention and access for those records before enabling bulk exports.

Propose a matrix before the pilot: correct customer and editable order; another tenant’s order; missing role; invalid address; an order shipped during evaluation; unavailable policy; and an alternative queue entry point. Set the expected outcome for each case and inspect persisted state. A polite agent response does not prove that the write was blocked. Use synthetic data and test destinations to avoid affecting real operations.

Measure incorrect blocks of legitimate actions, executed unauthorized actions, paths without a decision and added latency percentiles. Define thresholds according to risk and your product’s response-time budget; we attribute no improvement figures to the vendor here. Also review how much manual work denials create. The exit criterion should combine state integrity with operational viability, rather than merely an absence of SDK errors.

The launch offers a useful occasion to review where observation ends and effective control begins. Its value for your team depends on covering real paths, supplying decisions with trustworthy data and checking failure behavior. A detector can be wrong, a policy can be poorly designed and a tool can have an alternative access path. Keep permissions limited and preserve the business system’s own controls.

Start with one operation, complete the six criteria and expand scope using evidence from that pilot. If you need to define that boundary, Wasyra’s custom agent service can be a starting point for discussing architecture and integration. Bring a concrete operation, its identity sources and its consequences: they are better decision inputs than a list of tools.