Agent guards

AI agents turn model output into real actions: sending email, changing records, accessing sensitive data, and calling third-party services. Agent guards give security teams central control over those actions with remote policies that can change as risks and requirements evolve, without changing the agent’s code.

Developers add one enforcement point immediately before a tool or action and map trusted application context into it. Security teams define the policy for that action in Arcjet using its stable label. Every attempted action receives an ALLOW or DENY decision before the side effect runs, making enforcement deterministic even when model behavior is not.

Agent guards work inside tool handlers and other action boundaries without an HTTP Request. This is where Arcjet can use the actor, action inputs, and application context that model gateways and network controls cannot reliably infer.

┌──────────┐  proposed call  ┌─────────────┐  ALLOW  ┌─────────────┐
│ AI agent │────────────────▶│ Agent guard │────────▶│ Tool action │
└──────────┘                 └──────┬──────┘         └─────────────┘
                                   │
                                   │ DENY
                                   ▼
                             ┌──────────────┐
                             │ Action stops │
                             └──────────────┘

Where enforcement runs

The enforcement point runs in your application, immediately before the side effect. The final decision can combine:

SDK rules in code, such as rate limiting or prompt injection detection.
Agent guard remote policies, selected by the guard label and configured centrally by a security team.
Local evaluation, currently sensitive information detection over an explicitly marked local string.
Server evaluation over the actor and explicitly marked server inputs.

The application owns the final enforcement point. Direct guard() calls return a decision, while framework integrations place the same check around a tool automatically.

Agent guards and request protection

Use the API that matches the enforcement boundary:

	Agent guards	Request protection
Entry point	`guard()`	`protect()`
Protects	Tool calls, agent actions, queue jobs, workflow steps	HTTP routes and API requests
Input	`label`, optional `actor`, typed policy inputs, SDK rules	Request and request-specific rule inputs
Remote configuration	Agent guard remote policies, selected by `label`	Request Remote rules, scoped to a site

Next steps

Guard one tool call Add an explicit enforcement point before one action.

Framework integrations Wrap Vercel AI SDK and LangChain tools.

Remote policies Configure labels, actors, typed inputs, and supported policy rules.

Testing and reference Test denial and availability behavior and review the API.