Arcjet is en guarde in agentic workflows with Guard
Agents have gone to work – on tasks, yes, but also on code i.e. making requests within live production systems to invoke, connect and make tool calls in ways that we would perhaps not have envisaged half a decade ago.
The reality means that developers today need extended capabilities in terms of runtime security model controls to oversee agent workflows.
Arcjet thinks it has the answer.
The company this week introduced Guards, a service designed to enforce security inside AI agent workflows, queue consumers (application code that queues for service requests, not people in line at the supermarket – although in a roundabout way, that too) and other application code that doesn’t run behind an HTTP request.
As more application logic moves into long-running agentic systems, the security tools built around the “request boundary” (by which we mean proxies, web application firewalls, HTTP middleware) can no longer see where untrusted input arrives.
Guards extend Arcjet’s runtime protection into those code paths.
Beyond single request simplicity
Arcjet CEO David Mytton: Security has to live where the code lives.
Modern AI systems don’t run through a single request anymore. Agents call tools, pull in external data and “pass state” across long-running workflows. Most of that execution never touches an HTTP boundary, which means traditional security controls never see it.
What all this means is that developers apply rules directly where untrusted input enters the application, whether that input comes from a tool call, a queue message, or a workflow step.
That’s good, on the face of it, but it’s not good enough.
Why…? Because, this action puts enforcement where the application’s real context lives – identity, session state, prior tool outputs, business logic – rather than at a network boundary that can’t see any of it.
“Security has to live where the code lives. For agentic systems, that means inside the tool calls and workflow steps where untrusted input actually arrives, not at a perimeter that no longer exists,” said David Mytton, CEO at Arcjet. “Guards give developers a way to enforce policy inside the code paths agents use every day – the same place the threat model now lives.”
Guards integrate directly into Arcjet’s application-layer security model. Developers define rules in the same codebase as the feature itself, so protection ships with the code and gets reviewed in the same pull request. There is no separate system to manage.
With Guards, teams can:
- Detect prompt injection in tool results before they re-enter model context.
- Block PII in tool inputs and queue messages before they reach third-party models.
- Enforce per-user token budgets and spend limits inside agent loops.
- Validate untrusted input in workflow steps, background jobs and other non-HTTP code paths.
- Guards work alongside existing capabilities such as Arcjet Shield for public endpoints, sensitive data detection before model context is built and bot detection for high-cost AI routes. Together, these protections cover both the boundary and the execution layer inside the application.
Guards is available now through the Arcjet JS and Python SDKs. Existing customers can enable it immediately; new developers can get started with a free trial.
The Computer Weekly Developer Network (CWDN) spoke to Mytton for more.
CWDN: How will Arcjet’s internal runtime model specifically outperform traditional network-based WAFs when protecting complex, multi-step agentic tool executions?
Mytton: The risk scenario is an agent escalating privilege across steps, draining a budget, or calling a tool with arguments derived from untrusted context several hops back. That requires application-state awareness – identity, session, route and the tool call itself – which only runtime enforcement inside the application can see. The WAF was built for a world where the HTTP request was the unit of intent. With agents, the unit of intent is the tool call, and that lives below the HTTP boundary.
CWDN: Since Guards integrate directly into code, how do you ensure security policies remain consistent across polyglot microservice environments?
Mytton: Generic policies can be configured remotely through our cloud service and then applied to every application request. However, the most powerful and accurate policies always need to be close to the code they’re protecting – this is why it’s important for developers to take ownership of security just like they have responsibility for the database schema or observability.
CWDN: With logic moving away from HTTP boundaries, what is your long-term vision for the relevance of traditional perimeter security?
Mytton: The perimeter still matters for things the perimeter is good at: volumetric DDoS, geographic blocking, certificate termination. What’s changed is that an increasing share of security-relevant decisions can’t be made there anymore, because the request hitting the perimeter no longer represents the full intent. The perimeter isn’t going anywhere, but the runtime layer is where the next decade of investment is going, because that’s where the new threat surface actually lives.
CWDN: Can you explain how Guards effectively manage per-user token budgets when agents operate within highly unpredictable and recursive loops?
Mytton: Recursion is a non-issue from an enforcement standpoint – the SDK is invoked at every tool call, so every leaf in the loop goes through the same check against the same per-user counter, regardless of how deep the agent goes. Deciding what to do when a budget trips mid-loop – fail the call, degrade to a cheaper model, or return the limit back to the agent so it can replan – is a critical decision. Guards surfaces those as explicit policy choices rather than hiding them, because the right answer depends on the application.
