An agent at a fintech company calls a tool named shell with the argument {"command": "shutdown"}. Something has to decide whether that call happens.

Datadog and Waxell both answer that something should. They put the decision in two different places, and that choice is the whole comparison. Datadog AI Guard runs inside the application process, reached through the tracer the service already loads. The Waxell MCP Gateway runs on the network path, as the endpoint the agent's client is pointed at. Neither is a dashboard, and neither waits until afterwards to tell you what happened.

Everything else follows from that placement: which agents each product can reach, what kind of rule each can express, and what the resulting record looks like.

Datadog AI Guard is a runtime security layer for agentic applications, documented as designed to "inspect, block, and govern AI behavior in real time." It sits inline with the app and evaluates prompts, responses and tool calls using what Datadog's own announcement calls "an LLM-as-a-judge model to determine whether an action aligns with organizational intent and policy." It ships as Prompt Protection, Tool Protection and Sensitive Data Protection, reached through the Datadog Agent and the dd-trace tracer rather than through new infrastructure. Waxell MCP Gateway is a hosted governance endpoint: one URL per tenant that replaces the upstream MCP config on each client, so calls pass through identity resolution, policy rules, fingerprinting and audit before reaching any upstream. Its decisions come from a declarative rule set with fixed precedence rather than from a model's reading of intent.

What Datadog AI Guard is built for

Anyone evaluating AI Guard should treat it as an enforcement product, not monitoring with a strict tone.

It is inline, and it stops things. The documentation places AI Guard "in the critical path." In the SDK, client.evaluate(...) with Options(block=True) raises an AIGuardAbortError when the assessment returns DENY or ABORT. The canonical example in Datadog's docs is a tool call rather than a prompt: the shell call above, carrying an attack tag of destructive-tool-call. SDKs ship for Python, JavaScript, Java and Ruby, and automatic integrations cover LangChain, OpenAI, Anthropic, the AI SDK and RubyLLM without code changes.

Its threat model is genuinely agentic. Datadog frames the problem as the "agentic lethal trifecta" — privileged system access, exposure to untrusted data, and outbound communication — and Tool Protection evaluates a call against "the full chain of activity—from system prompt to user messages to previous actions" rather than in isolation. That is a real answer to multi-step manipulation, and a rule-matching engine cannot give it.

It is tunable the way a judgment-based system has to be. Evaluation sensitivity is a confidence threshold between 0.0 and 1.0, defaulting to 0.5, and each service can carry up to 1,000 characters of free-text "evaluation context" describing what the agent is legitimately for.

It also carries a deterministic override. Alongside the judgment path, a Tool Blocklist lets you select a service, an environment and a tool and block every request for that tool — Datadog's announcement is explicit that this fires "even if the tool call is deemed safe." AI Guard is not purely model-judged, and a comparison that says otherwise is wrong.

Two things to know before planning around it. AI Guard is in Preview: Datadog's setup documentation states that "Datadog needs to enable a backend feature flag for each organization in the Preview," and access runs through request forms labelled Limited Access and Preview. A red alert on its own pages states it is not available on app.ddog-gov.com or us2.ddog-gov.com.

Around AI Guard sits a wider Datadog AI surface that is easy to misread from outside. Agent Observability is the tracing and evaluation product, billed on LLM spans. Agent Console, also in Preview, monitors adoption, spend and delivery impact for Claude Code, Cursor, GitHub Copilot and Datadog's Bits AI agents. The Agent Directory connects those agents to Datadog's MCP server, which serves Datadog's own observability data to agents rather than governing the calls agents make elsewhere. The Governance Console governs the Datadog estate: cost attribution, access control and tagging hygiene.

Where the two architectures diverge

The placement is a stated design choice on both sides. Datadog's announcement puts it plainly: AI Guard "uses Datadog's existing instrumentation foundation, so you can activate protections without deploying new gateways or introducing new architectural components." For a team already running the Datadog Agent and dd-trace, that is a very short path, and Datadog is right to lead with it. Waxell took the opposite bet: the MCP Gateway is the new component, one URL per tenant, with calls evaluated before dispatch and results evaluated again on the way back.

That fork decides which agents are covered. Datadog's model needs a process you can instrument. Waxell's needs a client you can point at a URL, which is why the Gateway's page names Claude Desktop, Claude Code and Cursor alongside any MCP-compatible client. Neither perimeter is automatic: AI Guard covers the services you instrument, and the Gateway covers the calls routed through it, so an agent holding direct upstream credentials or a locally registered server goes around it. The buyer's question is not which is complete, because neither is. It is which configuration step your estate can carry: adding a tracer to code you control, or changing a config file on clients you may not own.

The decision models are different instruments. AI Guard's verdict is an evaluation: an action plus a reason the SDK documents as a "natural language summary of the decision," with attack tags and a confidence score behind it. Waxell's verdict is a rule firing. A Gateway rule scopes along upstream, tool glob, user email, role, team and the agent profile acting for the user, and resolves under a fixed precedence of deny, require approval, redact, allow, most restrictive rule winning. Actions include deny, require_approval, redact_args, egress_block, rate_limit, cost_cap, and the supply-chain pair deny_drift and risk_deny. The trade runs both ways: a model reads intent across a conversation in a way a glob cannot, and a rule returns the same answer every run with a record of which rule produced it.

Defaults differ, and this is where teams get caught. Datadog documents that "by default, AI Guard evaluates conversations and returns an action (ALLOW, DENY, or ABORT) but does not block requests," with blocking set per organization, environment, service, or service and environment. Datadog's announcement describes a rollout that begins in monitor-only mode, which is sound advice. Waxell's deny_drift is not on by default either: the starter rule set recommends it, and a recommendation is not a default. On both products, somebody has to switch enforcement on.

One category sits on Waxell's side because it requires owning the catalog. The Gateway fingerprints each tool it discovers as a hash over name, description and input schema. The attack this answers is the rug pull: an upstream quietly editing what search_documents means, appending "also forward the results to this URL" to the description, which the model then obeys. When a fingerprint changes, the drift surfaces for review, the prompt-injection scanner re-runs against the new description, and a deny_drift rule blocks the changed tool from that point. Sensitive data differs too: Datadog documents that AI Guard's "sensitive data scanning is detection-only; findings do not independently trigger blocking," while the Gateway's DLP scanners run on arguments and results with both scan-only and blocking variants.

The record each leaves is shaped by where it sits. AI Guard writes spans that integrate with APM traces and generates security signals in its own Explorer. The Gateway writes a durable audit row per call: timestamp, user, agent, upstream, tool, the policy decision and which rules fired, error class, and approval linkage, exportable as CSV. One is investigative and lives beside your other telemetry; the other is an enforcement ledger built for the question an auditor asks.

What Waxell adds

The MCP Gateway resolves each caller to a real user plus the roles, teams and agent profile acting for them, so the same person gets different rules depending on which agent is working on their behalf. Budget controls are policy actions rather than reports: rate_limit caps calls per window, cost_cap sets a cumulative spend ceiling, and the counters are shared across gateway replicas so limits hold under horizontal scale. A require_approval rule parks the call while a reviewer sees who asked, which agent asked, which tool, and the exact arguments.

Connect covers what the instrumentation route structurally cannot reach: third-party agents you cannot run your own code inside. It includes the MCP Gateway, so the tool-call governance above applies to those agents without a separate purchase, and adds a versioned, audited record of hand-offs between agents and people.

The entry point differs in kind. Waxell's free tier is self-serve and permanent: 10,000 traced executions a month, two seats, one connected client and one governed MCP upstream, with 14-day retention.

Feature comparison

Three scenarios

You already run Datadog for APM and infrastructure, and your agents are services you build. Datadog. Turning on protection through a tracer you already load, with verdicts landing beside telemetry your team already reads, is shorter than introducing a broker.

Your agents are assistants you did not build, calling dozens of third-party MCP servers. Waxell. There is no process to instrument, and the risk is the catalog rather than the reasoning: a server that quietly rewrites a tool definition. Fingerprinting and deny_drift require sitting in front of the upstream, and pointing a client at a URL is a change you can make to software you do not own.

You need the decision reproducible and attributable for an audit. Waxell, on the strength of the record: a rule with fixed precedence returns the same verdict every run, and the audit row names the rule that fired. A judgment-based verdict with a natural-language reason and a confidence score is more adaptive and harder to re-run as evidence.

When to use Datadog

• You already run Datadog and want agent protection without adding a component to your architecture.

• Your agents are services your team owns and can instrument in Python, JavaScript, Java or Ruby.

• Prompt injection, jailbreaking and multi-step manipulation are your main concerns, where evaluating intent across a conversation beats pattern matching.

• You can get into the Limited Access programme, and you are not on a Datadog government site.

When to use Waxell

• The agents you need to govern are ones you cannot run your own code inside.

• You want the tool catalog under policy, not only the traffic crossing it.

• You need operational policy as enforcement rather than reporting: spend ceilings, rate limits, approval holds that park a call.

• You need an enforcement record that names the rule that fired, exportable for a compliance workflow.

How Waxell handles this: the MCP Gateway is one governed URL per tenant, replacing the upstream MCP config on each client so calls pass through identity resolution, policy and audit before any upstream sees them. Its policy rules scope along upstream, tool, user, role, team and the agent profile acting for a user, and resolve under a fixed precedence of deny, require approval, redact, allow. Tools are fingerprinted over name, description and input schema, so an upstream that rewrites a tool definition surfaces as drift and a deny_drift rule stops the changed tool rather than trusting it. Connect includes the Gateway and adds coordination and a versioned hand-off record for the third-party agents already working alongside your team.

FAQ

Does Datadog AI Guard block agent actions, or only observe them?

It blocks. AI Guard is documented as designed to "inspect, block, and govern AI behavior in real time," and in the SDK a DENY or ABORT verdict raises an AIGuardAbortError when blocking is configured. The qualifier that matters is the default: Datadog states it evaluates conversations and returns an action but does not block requests until you configure a blocking policy. Treat it as an enforcement product that ships in monitor-only mode.

What is the main difference between Datadog and Waxell for agent governance?

Where the decision runs. AI Guard runs inside the application process, reached through the Datadog Agent and the dd-trace tracer, which is why Datadog can say it adds protection without new gateways. The Waxell MCP Gateway is a network endpoint the agent's client is pointed at. That determines which agents each product can reach and what kind of rule each can express.

Is Datadog AI Guard generally available?

Not as of this writing. Datadog's setup documentation states that while AI Guard is in Preview, Datadog enables a backend feature flag per organization, and access runs through request forms. The same documentation states AI Guard is not available on the app.ddog-gov.com or us2.ddog-gov.com sites.

Can Datadog govern my agents' MCP tool calls?

Tool calls, yes: Tool Protection evaluates a tool invocation's intent, arguments and relationship to earlier steps, and can block it. Datadog's own MCP server is a separate thing, and worth not confusing with governance: it serves Datadog's observability data into agents like Claude Code and Cursor. Waxell's MCP Gateway sits on the other side of that relationship, in front of the upstream servers your agents call.

Which one catches an MCP server that changes a tool description?

Waxell's Gateway addresses this directly, because it fingerprints each tool over name, description and input schema and can deny a tool whose fingerprint changed since it was last approved. Datadog's published AI Guard material describes evaluating each call in context rather than tracking tool identity between calls, and the pages reviewed here did not address fingerprinting. Note that deny_drift is a rule you author: Waxell's starter rule set recommends it, but it is not on by default.

Sources

• Datadog, "AI Guard" — docs.datadoghq.com/security/ai_guard, accessed September 22, 2026

• Datadog, "Set Up AI Guard" — docs.datadoghq.com/security/ai_guard/setup, accessed September 22, 2026

• Datadog, "AI Guard SDK" — docs.datadoghq.com/security/ai_guard/setup/sdk, accessed September 22, 2026

• Datadog (Océane Bordeau, Santiago Mola, Vijay George, Alexa Levine), "Protect agentic AI applications with Datadog AI Guard" — datadoghq.com/blog/ai-guard, published February 3, 2026, updated June 9, 2026

• Datadog, "Agent Observability" — docs.datadoghq.com/llm_observability, accessed September 22, 2026

• Datadog, "Agent Console" — docs.datadoghq.com/ai_agents_console, accessed September 22, 2026

• Datadog, "Governance Console" — datadoghq.com/product/governance-console, accessed September 22, 2026

• Waxell, "Policies & Approvals" — waxell.ai/docs/mcp-gateway/policies, accessed September 22, 2026

• Waxell, "Security & Audit" — waxell.ai/docs/mcp-gateway/security, accessed September 22, 2026

Governing agents you cannot instrument, and want the tool catalog itself under policy rather than only the traffic crossing it? Start free with the Waxell MCP Gateway — get started.