Anomity Integrates with Datadog Cloud SIEM

Anomity now integrates with Datadog Cloud SIEM. Connect from Settings, Integrations with a Datadog API key and your Datadog site, and Anomity forwards its findings, console audit events and guardrail decisions to Datadog Logs, where Cloud SIEM detection rules run over them. It is available today in the Anomity console.

This post covers what is forwarded, the exact shape of each log, how delivery survives an outage or a revoked key, and where to point your first detection rules.

Why Datadog Cloud SIEM, and why now

Security teams that run their SOC in Datadog asked a simple question: where do Anomity's events go when the console is closed? Endpoint and network tools already feed the SIEM, but the AI agent layer mostly does not. An EDR sees a process start. It does not see that the process was a coding agent, that a new MCP server was wired into it this morning, or that a guardrail just denied a tool call that would have read a credentials file. That is the record we argued for in our guide to AI agent audit trails, and it belongs where the SOC already correlates and alerts.

One design decision shapes everything else: SIEM forwarding is a firehose, not a notification rule. Anomity's people-facing channels, such as the Slack app, Google Chat and the outbound webhook, deliver what a notification rule matches, because a person should only be interrupted for what matters. A SIEM is the opposite: it does its own filtering, and a feed that only contains what someone remembered to write a rule for has gaps nobody can see. So every event is queued for Datadog before any notification rule is consulted.

What Anomity sends

The install carries a switch per family, and all three are on by default. Three things are deliberately not forwarded: device-level configuration diffs, whose volume we have not sized yet; scheduled digests, because a roll-up is not a security event; and anything from before you connected, because there is no backfill.

The log schema is a contract

Detection rules, facets and log pipelines all compile against attribute names, so we treat the shape of each log as a published contract. A violation arrives like this:

{
  "ddsource": "anomity",
  "service": "anomity",
  "ddtags": "anomity_event:violation",
  "hostname": "eng-laptop-042",
  "message": "Claude Code session ran without permission prompts",
  "status": "error",
  "evt": { "name": "violation" },
  "anomity": {
    "schema_version": 1,
    "eventType": "violation",
    "severity": "high",
    "policyType": "runtime_bypass",
    "policyName": "Unattended agent session (runtime bypass)",
    "description": "Claude Code session ran without permission prompts",
    "id": "<finding id>",
    "findingStatus": "open",
    "deviceId": "<device uuid>"
  }
}

Four choices in that shape are worth knowing before you write a rule:

• Everything Anomity-specific lives under anomity. Root-level status is Datadog's reserved log-level attribute. A finding's lifecycle status merged at the root would be read as a level and shift severities, so the root carries only the reserved attributes we mean, with severity mapped critical to critical, high to error, medium to warn and low to info. The lifecycle value is published as anomity.findingStatus so one word never means two things.
• The anomity block is an allowlist, not a passthrough. It is built field by field from a fixed list. Anything else attached to an internal event is dropped, so a field leaves the platform only when we decide to publish it, and a stray secret-shaped value never rides along.
• Devices are typed. A device UUID goes to anomity.deviceId and a hostname to anomity.deviceName, never one facet holding both. The hostname also fills root hostname, which Datadog's host view and per-host rules key on.
• anomity.schema_version is on every log. Adding a field is additive and safe. Renaming or removing one bumps the version, so a pipeline can branch on it rather than guess.

How delivery works

A dropped chat alert is recoverable, because the finding is still in the console. A gap in a SIEM stream silently breaks detections with no second source. That is why this path gets a durable outbox.

• Queued, then drained. Events are written to a per-organization outbox on the hot path and drained every minute in batches of up to 500, comfortably inside Datadog's intake limits.
• Retries are safe. Datadog's log intake takes arrays and is append-only, so a batch that timed out can be re-sent without risk. Timeouts, 429s and 5xx responses are retried on the next drain, up to ten attempts.
• A revoked key does not lose data. A 401 or 403 stamps the card Reconnect needed and stops draining that organization, but keeps its events queued for up to seven days. Reconnecting delivers the backlog.
• A rejected payload is visible. If Datadog refuses a batch outright, retrying identical bytes cannot succeed, so the batch is dropped and the count appears on the card instead of disappearing.
• The key is checked every six hours. Only an explicit authentication failure changes the card's state, so a network blip never flips it to Reconnect needed.
• One customer's problem stays theirs. Each organization drains independently, and a forwarding failure can never affect Anomity's own notification delivery.

How setup works

1. In Anomity, open Settings, Integrations, Datadog. Paste a Datadog API key and choose your site, which is the domain in your own Datadog URL: datadoghq.com, datadoghq.eu, us3, us5, ap1, ap2 or ddog-gov.com.
2. Anomity validates the key with Datadog for that site before saving it. An invalid key is never stored. A valid one is encrypted with AES-256-GCM and never returned by any endpoint, not even masked.
3. Click Send test event. It goes straight through, bypassing the outbox, so you see an immediate pass or fail.
4. In Datadog, enable Cloud SIEM and make sure its index is ordered first in your log indexes, which Datadog requires for detection rules to run.
5. Build rules over source:anomity. The best discriminator is @anomity.policyType; @evt.name, status and @anomity.decision cover audit actions, severity and guardrail outcomes.

The site you pick is mapped to Datadog's intake host through a fixed table, so the destination of every request is set by Anomity, never by a free-text value.

Detection rules worth writing first

Datadog does the correlation; the useful work is choosing which Anomity signals deserve a rule. These are the ones we would start with, each keyed on a single attribute:

• Runtime permission bypass, @anomity.policyType:runtime_bypass: an agent session actually ran without human review, for example with permission prompts skipped.
• Agent self-modification, @anomity.policyType:self_modification: an agent's own configuration gained an MCP server, a permission grant or a hook while it had a live session, the endpoint signature of prompt-injection persistence.
• Secret paste blocked, @anomity.policyType:paste_secret_blocked: the Browser Sensor stopped a credential from reaching an AI site.
• Sensitive file uploaded to AI, @anomity.policyType:sensitive_file_uploaded_to_ai.
• Unvetted MCP server, @anomity.policyType:mcp_vetting: an MCP server that is not on your approved list appeared on an endpoint.
• Guardrail deny burst, @anomity.eventType:hook @anomity.decision:deny with a threshold: repeated blocked tool calls from one host, the pattern our incident response playbook treats as a reason to pull an agent's autonomy.

The guardrail events come from the enforcement point described in how Claude Code hooks work: Anomity decides before the tool call runs, and Datadog now gets a record of every time it said no.

How Anomity and Datadog fit together

Datadog Cloud SIEM is where your SOC correlates, detects and investigates across every source it ingests. Anomity covers the layer those sources miss: the Endpoint Sensor inventories agents, MCP servers, extensions, plugins, skills, secrets, hooks, CLIs and local LLM runtimes; the Browser Sensor covers AI web services, the accounts used in them and the secrets pasted into them; and cloud discovery reads the AI applications holding OAuth grants in your SaaS. On agents that expose a hook, Anomity decides allow, deny or log before a tool call runs. The integration puts all of that in front of the detection engine you already trust.

Datadog is one destination among several. The same events can go to any SIEM through an OpenTelemetry Collector with Anomity's OTLP forwarding, or into Rapid7 InsightIDR, and a finding that needs an owner can open a ticket in Jira. A workflow of your own, from an on-call page to a spreadsheet row, can start from the Zapier app. Anomity collects metadata only, redacts secret values on the endpoint, and is SOC 2 Type II attested. To see your own fleet's agent events in Datadog, book a 30-minute demo.