Arcjet vs Datadog AI Guard
Looking for a Datadog AI Guard alternative? Arcjet vs Datadog AI Guard turns on where content is inspected and who authors the rule.
Both evaluate AI application activity at runtime. Datadog AI Guard is an evaluator that you call from your application, with policy configured in Datadog. Arcjet runs inside your application, in request handlers and on agent tool calls and jobs. It keeps sensitive-information inspection in your own process. It also accepts app-specific rules in code, plus operational remote rules that a security team changes from the Arcjet dashboard or MCP.
This comparison uses primary documentation reviewed on August 13, 2026, and avoids inferring undocumented behavior. Products change, so check the linked sources before you decide.
What Datadog AI Guard does
AI Guard integrates through an SDK or an HTTP evaluator, with automatic and manual framework integrations, and documents SDKs for Python, JavaScript, Java, and Ruby. The application sends prompts or tool calls for evaluation and receives a verdict.
You configure policy in Datadog under Security > AI Guard > Settings, covering service policy, blocking, sensitive-data settings, tool blocks, and sensitivity. Datadog also documents that application-supplied system prompts can add evaluation context but cannot disable or weaken AI Guard's security checks. That's a deliberate design choice: it keeps the application from loosening a control that the security team set.
It arrives with the rest of Datadog. If your traces, logs, and detections already live there, AI evaluation lands in the same place, with the same access model and the same on-call surface.
Where they differ
| Area | Datadog AI Guard | Arcjet |
|---|---|---|
| Integration | SDK or HTTP evaluator call from the application | SDK imported into the application |
| Where content is inspected | Prompts and tool calls are sent to Datadog for evaluation | Sensitive-information detection runs in-process (built-in local engine, optional on-device ML model) and the raw body is never transmitted; rate limiting and prompt-injection detection do call the Cloud API |
| Where rules are authored | In Datadog, under AI Guard Settings | App-specific rules in code. Operational HTTP rules in the Arcjet dashboard or through MCP. Labeled tool-call policies are a separate system. |
| Can application code define the rule | No. System-prompt context adds evaluation input but cannot disable or weaken checks | Yes. You write and review rules with the feature |
| What it takes to block | An SDK call can request exception-based blocking, and the remote service policy must also have blocking enabled | Your application receives an allow or deny and acts on it before the side effect |
| Non-AI application surface | Covered by other Datadog products, not AI Guard | Same SDK also covers bots, rate limiting, WAF rules, and email validation |
The difference that usually decides it
AI Guard evaluates by receiving the content. That's how an external evaluator works, and it means that prompts and tool calls leave your environment for evaluation.
Arcjet's sensitive-information detection runs entirely in-process: a built-in local engine, plus an optional on-device ML model for names, addresses, and government or financial identifiers. The raw request body is never sent. If the content carries a residency or minimization obligation, there's no transfer to review. Rate limiting and prompt-injection detection do call the Cloud API, so this is a claim about content inspection, not about every rule. For more information about local inspection, see keeping security inspection local.
If your prompts aren't regulated content, this difference might not matter to you, and the rest of the comparison is where to look.
Who authors the rule
AI Guard centralizes policy in Datadog, and prevents application code from weakening it. For an organization whose main risk is an application team turning a control down, that's the right default.
The cost is that the application team can't express a rule that needs their context. "This refund is above the threshold for this plan tier" is a policy statement that requires knowing the plan tier, the refund amount, and the account. You have to write it where those values exist.
Arcjet supports both. App-specific rules stay in code because they need application context: route, user, plan, prompt, tool call, or body. That includes per-user token budgets, prompt injection, and PII. Operational HTTP rules (bots, Shield WAF, filters, fixed-window and sliding-window rate limits) change in the Arcjet dashboard or through MCP and take effect immediately, still inside the application. You set token-bucket budgets in application code. Labeled tool-call policies are a separate system.
When a security check can't finish (a timeout, a transport issue, or an incomplete policy), you choose what happens next. A direct Guard call returns allow with error codes rather than treating the incomplete check as a denial. Vercel AI SDK and LangChain wrappers fail closed unless you opt into continuing on error. HTTP request checks can fail open when Arcjet's cloud can't be reached; that's configurable. If you can't accept a check that didn't finish, look at the error codes. See the Guards reference.
In the SDK, those two surfaces are protect() (HTTP request handlers) and guard() (tool calls and jobs). JavaScript and Python are the documented languages for the tool-call path; Go is pre-release. For more information about treating code and remote policy as separate authoring models, see application-native vs remote security policies.
When to choose which
Datadog AI Guard fits
Datadog AI Guard fits when both of the following apply:
- You're already standardized on Datadog, and you want AI evaluation to arrive through the same instrumentation, access model, and alerting as everything else.
- Centrally authored policy that application code can't weaken is the property you want most.
Arcjet fits
Arcjet fits when any of the following apply:
- Content inspection needs to stay in your environment.
- Rules need application context to be worth writing.
- You want the same enforcement layer covering tool calls, queue consumers, and background jobs alongside HTTP routes.
- Engineers and the security team both need a route to policy against one enforcement point.
They can coexist. Datadog remains the place your traces and detections live, and in-code enforcement is what returns a decision that your application acts on before the side effect. A buyer question for any runtime control: can you reconstruct the sequence of actions in a run? Arcjet tags related decisions with a correlation ID so the run is reconstructable for investigation.
Compare in detail: Arcjet vs Rein Security · AI agent security platform category map
Frequently asked questions
How is Arcjet different from Datadog AI Guard?
Datadog AI Guard is an evaluator your application calls, with policy configured in Datadog under AI Guard Settings. Arcjet runs inside your application, keeps sensitive-information inspection in-process so the raw body is never transmitted, and keeps app-specific rules in code while operational HTTP rules change from the Arcjet dashboard or MCP.
Does Datadog AI Guard send my prompts to Datadog?
Datadog documents that the SDK sends prompts or tool calls for evaluation, which is how an external evaluator works. Arcjet's sensitive-information detection runs entirely in-process: a built-in local engine, plus an optional on-device ML model for names, addresses, and government or financial identifiers. The raw request body is never sent. If the content carries a residency or minimization obligation, there is no transfer to review. Rate limiting and prompt-injection detection do call the Cloud API, so this is a claim about content inspection, not about every rule.
Can application code change a Datadog AI Guard policy?
Datadog documents that application-supplied system prompts can add evaluation context but cannot disable or weaken AI Guard's security checks, and that an SDK request for exception-based blocking still requires blocking to be enabled in the remote service policy. That is deliberate, and it also means an application team cannot express a rule needing context only they have.
Can I use both Datadog AI Guard and Arcjet?
Yes. Datadog remains where traces and detections live, and in-code enforcement returns a decision your application acts on before the side effect executes.
AI runtime security in your code
Protect your AI agent workflows with Arcjet
Arcjet runs inside your application, where it can use runtime context to enforce agent actions and budgets, detect prompt injection, and protect sensitive information before a workflow acts.