The prompt injection stopped in the call,
with the evidence in the trace.
Datadog AI Guard sits around each model call and tool call your agent makes. It evaluates the prompt, the response and the tool invocation for prompt injection, tool misuse and sensitive data exfiltration, and allows or denies each one with a reason recorded in the trace. We wire it into the agents you run, operate it monitor-only until the denials are understood, move it to block mode per agent, and review what it stopped every month.
Quick facts
Related
- Agent Observability, the traces, tokens and evaluations this adds a verdict to
- Datadog for AI, the group: observability, protection and GPU for AI workloads
- Sensitive Data Scanner, the rules that find credentials and personal data in the evaluated conversation
A verdict on every call the agent makes, kept next to the call itself
An agent that can read a document and then send an email will, eventually, be handed a document that tells it to send an email. The model cannot be relied on to notice. AI Guard evaluates the tool call before it runs, denies it, and leaves a span in the trace that shows the document, the instruction and the denial, in order.
Evaluated at three points. The prompt going in, the response coming out, and each tool call the agent attempts. Categories include indirect prompt injection, policy evasion, credential access and data exfiltration. The verdict is ALLOW or DENY, with the reason.
Two modes, chosen per agent. Monitor-only records the DENY and lets the call proceed, which is how the policy is learned. Block unsafe stops the call in the integration and raises an error in the SDK for your code to handle.
Wired where the agent already is. Automatic integrations for the common frameworks and SDKs need configuration, not code. The SDK covers custom agents in four languages. The HTTP API covers the rest with no Agent and no SDK, but its evaluations create no span and do not block: your code acts on the verdict.
The evidence is the trace. Each SDK or integration evaluation is an AI Guard span inside the Agent Observability trace. When a customer asks what the agent was prevented from doing last quarter, the answer is a query, not a reconstruction.
Left in monitor-only forever, rate-limited into silence, and a block the application did not catch
How it bills. AI Guard is billed on the input tokens it evaluates. Each organisation also has usage limits on evaluated tokens and requests per minute, and past them the integrations let the call proceed unevaluated while the SDK raises an error. Datadog publishes the meters, rates and limits. The lever is which calls are evaluated. A retrieval step over the company handbook and a tool call that can transfer money are not the same risk, and evaluating both at the same depth sets the bill by the handbook.
The configuration traps. Monitor-only enabled during the rollout and never moved to block, so the denials are recorded for a year and the tool call that should have been stopped was recorded too. Block mode enabled without the SDK error being handled, so the first denial crashes the agent mid-conversation instead of declining the step. The usage limit reached during a traffic peak, so the integrations proceed unevaluated and nothing on the dashboard says so. A coding agent assumed to be covered because the Preview integration is installed, with nobody told that it is a Preview. The AI gateway plugin wired for one gateway while a second agent calls the model directly.
Field noteThe most common gap we see is an agent with a tool that can act, and no evaluation on the tool call. The prompt is guarded because that is where the examples are. The tool call is where the damage is, and it was wired after the first incident.
Field noteThe pattern we keep finding is monitor-only with nobody reading the monitor. The denials pile up in the trace. The team that owns the agent is shipping features. The decision to move to block was deferred until the denials had been reviewed, and the review was never scheduled.
Field noteThe first week in block mode produces denials that are the policy being wrong, not the user being malicious. A legitimate request phrased oddly, a tool call the agent needs for its own job. Each one is a tuning decision, and tuned without the agent's owner the policy ends up blocking the job the agent was built to do.
Field noteThe rate limit is the control nobody monitors. When it trips, the integration's behaviour is to proceed, which is the right default for availability and the wrong one for a control somebody has promised a customer is always on. For the length of the peak, the control a customer was told is always on was off, and the evaluations that never ran left no denials to review.
Tool calls first. Monitor-only until the denials are understood. Block per agent, with the error handled.
AI Guard is delivered inside the AI Observability Accelerator, four weeks, fixed scope, alongside Agent Observability. The traces come first, because a denial with no trace around it is a log line with no context. The sequence inside the accelerator is the same for every agent.
- Inventory the agents and what they can do. Each agent, its framework, its model calls, its tools, and which tools can change or send something. The owner of each. Agents that only read trusted internal data are noted as lower priority, not excluded.
- Choose the integration per agent. Automatic integration where the framework has one. SDK for custom agents. HTTP API for Go, .NET and anything else. Gateway plugin where traffic routes through one, with a check that nothing bypasses it.
- Wire the tool calls, then the prompts and responses. Evaluation on the tool calls that act is enabled first. Prompts and responses follow. Coding agent protection is enabled only with the Preview status recorded and agreed.
- Run monitor-only for a fortnight and read every DENY. Each denial is read against its trace with the agent's owner. Real attacks are recorded. Policy misfires are tuned. The categories to block are agreed in writing per agent.
- Move to block, with the error path built. Block unsafe enabled per agent, or the DENY acted on in code for HTTP API agents. The SDK error is caught and the agent declines the step rather than crashing. A monitor on the usage limit, so a rate-limited call that proceeds unevaluated pages someone.
- Hand over, in writing. Agent inventory and the integration chosen for each. Which categories block and which monitor. The denials reviewed and how each was resolved. The usage limit monitor, and the open items on the day we finished.
Access is admin on the Datadog organisation and read access to the deployment tooling that ships the agent's configuration. We do not need access to your model provider accounts or your prompts at rest. The evaluations reach Datadog through the integration, and the policy decisions are made with the team that owns the agent.
An agent gains a tool every sprint, and the policy was written for the tools it had
A new tool is added that can act. A new agent ships through a path the gateway does not see. A denial category that was tuned out for one agent is the one the next agent needed. Managed Observability is the monthly service that keeps the coverage and the policy matching the agents as they are now.
Every month, the denials are reviewed by agent and category. Each is read against its trace. Real attacks are reported to the owner with the span. Misfires are tuned. A rise in one category on one agent is raised before it becomes the pattern.
Coverage follows the agents. New agents and new tool calls found in Agent Observability without an AI Guard span are wired in. An agent still in monitor-only past its agreed date is moved to block or formally kept with a reason.
The limits are watched. Evaluated tokens and requests per minute against the organisation's limit. A peak that approaches it is raised before the integrations start proceeding unevaluated, and the monitor on that condition is tested.
The status is kept honest. Which agents are in block, which are monitor-only, and which rely on a Preview integration, is reported each month, so the answer to a customer's question about control is the current one.
We operate the stack. You own the product.
We are not an AI security company, and we do not pretend to be. We are a managed runtime operator. We run AI Guard inside your Datadog, next to the traces. We read what it denies and tune the policy with the team that owns the agent. We fix what sits in the runtime we operate and route the rest with the span attached. We operate and evidence the runtime controls that support your compliance obligations. The agent, its tools, its policy and the decision to let it act stay yours. Agents own the analysis. Humans own the outcome.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog AI Guard, answered plainly
What does Datadog AI Guard protect against?
Three things, in Datadog's own terms: prompt injection and jailbreaking, tool misuse, and sensitive data exfiltration. It evaluates the prompt going in, the model's response coming out, and each tool call the agent attempts, and returns ALLOW or DENY with a reason. In monitor-only mode the DENY is recorded and the call proceeds. In block mode the integration stops the call and the SDK raises an error for the application to handle. Every evaluation through the SDK or an integration is an AI Guard span in the trace, next to the model call it judged. HTTP API evaluations do not create spans.
How is Datadog AI Guard billed?
AI Guard is billed on the input tokens it evaluates. There are also per-organisation usage limits on tokens and requests per minute. Past the limit, automatic and manual integrations let the call proceed unevaluated, and the SDK raises an error. Datadog publishes the current meters, rates and limits. We do not publish prices. We do decide, with you, which agents and which calls are evaluated, because a retrieval step over trusted internal documents and a tool call that can send an email are not the same risk.
Is Datadog AI Guard generally available?
For custom agents, yes. The SDK for Python, Node.js, Java and Ruby, the automatic integrations for LangChain, the OpenAI SDK, the Anthropic SDK, the AI SDK and RubyLLM, and the HTTP API for other languages are all available. Protection for coding agents, with Claude Code as the named example, is in Preview. We say so plainly, we do not build a production control on a Preview feature without the customer knowing that, and we track the status so the page and the implementation change when Datadog's does.
Is Critical Cloud an AI security company?
No. We are a managed runtime operator. We run AI Guard inside your Datadog alongside Agent Observability, read what it denies, tune the policy with the team that owns the agent, fix what sits in the runtime we operate, and route the rest to the owner with the trace attached. Red-teaming your models, writing your AI usage policy and advising on AI regulation are not what we do. Where you have a security team working on AI, the evaluations and the spans reach them through the same routing.
What does Critical Cloud do with AI Guard every month?
Managed Observability reviews the DENY evaluations each month, by agent and by category. Each is checked against its trace to separate a real attack from a policy that is too tight. New agents and new tool calls are confirmed as wired through AI Guard. The usage limits are watched, so a rate-limited call is not silently proceeding unevaluated. We re-confirm which agents are in block mode and which are still monitor-only, and report what was denied, tuned and routed. A DENY for data exfiltration from an agent in monitor-only mode is raised with the owner that week.
- Datadog products: every product, and how we implement and run each one
- Agent Observability and Datadog for AI: the traces this adds a verdict to, and the group it belongs to
- AI Observability Accelerator: traces, evaluations and AI Guard on the agents you run, in four weeks
- Claude and MCP for Datadog: an agent with tools, and what it took to run it safely
Every tool call evaluated. Every denial in the trace.
Tell us which agents you run and which of their tools can act. We will show you which calls are evaluated today, which are not, and what it takes to put a verdict on every one of them.