--- title: "Anomity Now Forwards Security Events over OpenTelemetry | Anomity Blog" description: "Anomity now streams AI agent findings, audit events and guardrail decisions over OTLP to your OpenTelemetry Collector, with OCSF Detection Finding bodies." url: "https://anomity.ai/blog/anomity-opentelemetry-siem-integration/" source: html --- Anomity Now Forwards Security Events over OpenTelemetry Contents - Why OpenTelemetry, and why now - What it sends - What a record looks like A log level is not a security severity - Why the body is OCSF - How delivery works - How setup works - Current limits - How Anomity and OpenTelemetry fit together - Frequently asked questions 0% 8 min read Share - X.com - LinkedIn - Email - Copy URL - Copy markdown [← Back to blog](https://anomity.ai/blog/) - Home - Blog - Anomity Now Forwards Security Events over OpenTelemetry ![Anomity robot illustrating Anomity Now Forwards Security Events over OpenTelemetry] Company # Anomity Now Forwards Security Events over OpenTelemetry Anomity Research Anomity Research · Sep 24, 2026 · 8 min read Share: Copied TL;DR - Anomity now forwards security events over OpenTelemetry (OTLP) . Point it at an OTLP/HTTP endpoint you control, normally an OpenTelemetry Collector , and the collector routes the events on to whatever SIEM or data lake you run. - It is one vendor-neutral integration instead of a separate native build per SIEM. The events are the same three families every Anomity SIEM destination carries: findings, console audit events and guardrail decisions. - Finding-shaped events arrive with an OCSF Detection Finding (class 2004) body, so a SIEM that reads OCSF needs no hand mapping. Flat anomity.* attributes ride alongside for routing and filtering in the collector. - Delivery runs through a durable outbox : gzipped OTLP/JSON batches every minute, Retry-After honoured, partial successes never retried, and an anomity.event_id on every record so at-least-once delivery can be deduplicated. - Header values (your collector's auth token) are write-only : encrypted, never returned, never logged. Connect sends a real test record and stores nothing unless it arrives. - The scope is stated plainly: JSON over HTTP only for now, per-SIEM routing notes still to come, and a published egress IP list still to settle. Anomity now forwards security events over **OpenTelemetry**. Give it an OTLP/HTTP endpoint you control, normally an **OpenTelemetry Collector**, and Anomity streams its findings, console audit events and guardrail decisions there as OTLP log records, with finding-shaped events carried as **OCSF Detection Findings**. The collector sends them on to whatever SIEM or data lake you run. It is available today from the OpenTelemetry (OTLP) card under Settings, Integrations. This post explains why we chose one open protocol over a long list of native builds, what each record looks like, how delivery behaves when a collector misbehaves, and what is still to come. ## Why OpenTelemetry, and why now The SIEM row on our integrations page is long: Splunk, Microsoft Sentinel, Google SecOps, QRadar, Sumo Logic, Panther, Securonix, Exabeam and more. Building each natively means a separate auth scheme, payload format, failure taxonomy and settings card per vendor, and the customers asking for Sentinel are rarely the ones asking for Panther. [Datadog Cloud SIEM](https://anomity.ai/blog/anomity-datadog-cloud-siem-integration/) got a native build because its pipeline and detection-rule model reward one. For the rest, a native build each would be the largest integration backlog in the product. OTLP is the vendor-neutral answer. Anomity sends each event once, in one open format, to an endpoint you control. Your collector does what collectors are for: batching, enrichment, routing, and exporting to the SIEM and the data lake at the same time if you want both. One integration on our side covers most of the list. It is also not the same as pointing the outbound webhook at a SIEM. Webhooks, like [Google Chat](https://anomity.ai/blog/anomity-google-chat-integration/) and Slack, deliver what a notification rule matches, which is right for people and wrong for a SIEM. A SIEM feed needs everything, with no gaps that depend on which rules someone remembered to write, and it needs a durable queue behind it. This integration taps every event before rule matching, the same way the Datadog forwarding does. ## What it sends Event type What it is Record body `violation` A policy finding from the Endpoint Sensor, Browser Sensor or cloud discovery OCSF Detection Finding `new_mcp`, `new_skill`, `new_agent` An MCP server, skill or AI tool seen for the first time on the fleet OCSF Detection Finding `discovered_app` An AI application found by cloud discovery OCSF Detection Finding `hook` A guardrail decision at the agent hook: deny, warn or ask OCSF Detection Finding, with a disposition `audit` A cloud-scope change in the Anomity console Plain text description Findings, audit events and guardrail decisions each have a switch on the install, all on by default. Only events after you connect are forwarded, and device-level configuration diffs are not forwarded yet. OTLP carries traces, metrics and logs; a SIEM feed is logs only, one log record per security event. ## What a record looks like Each batch is one OTLP export request. The resource identifies the source with `service.name=anomity` and `anomity.tenant_id`, which helps anyone running several Anomity organizations into one collector. Each log record then carries flat attributes and a body: ``` { "eventName": "anomity.violation", "severityNumber": 17, "severityText": "high", "attributes": { "anomity.schema_version": 1, "anomity.event_id": "", "anomity.event_type": "violation", "anomity.severity": "high", "anomity.policy_type": "runtime_bypass", "anomity.policy_name": "Unattended agent session (runtime bypass)", "anomity.finding_id": "", "anomity.device_id": "", "host.name": "eng-laptop-042" }, "body": { "class_uid": 2004, "...": "the OCSF Detection Finding" } } ``` That is simplified for reading; on the wire it is standard OTLP/JSON, with attributes as key and value pairs and 64-bit values as strings. The details that matter for your pipeline: - Attributes are flat, allowlisted and named the OpenTelemetry way : lowercase, dot-namespaced, snake_case . That is what collector processors and OTel-aware parsers expect. The set is exactly the allowlist the Datadog integration publishes, so nothing new leaves the platform; OCSF is a re-encoding of the same fields, not a wider projection. - eventName is anomity. , because the structure of a record varies by event type. anomity.policy_type is the primary detection discriminator. - anomity.event_id is stable across retries. It is your deduplication key. - host.name follows the OpenTelemetry semantic convention, resolved from the device at delivery time. - anomity.schema_version is shared with the other SIEM destinations. Renaming or removing an attribute bumps it. ### A log level is not a security severity OTLP's `severityNumber` is a log level, and backends bucket it by range. We map Anomity severities into distinct ranges so ordering stays visible: critical to 21, high to 17, medium to 13, low to 10 and info to 9. Critical takes the top range rather than sharing high's, so a range-bucketing backend does not show the two identically. `severityText` carries our own word. **Key detection rules on anomity.severity or OCSF severity_id , never on the log level.** ### Why the body is OCSF OpenTelemetry defines no semantic conventions for a security finding. An OTLP record without a schema is an envelope around field names only we understand, and every customer would have to hand-map them, which is asking each customer to build the integration themselves. OCSF fills the gap. Every finding-shaped event carries an OCSF 1.3.0 **Detection Finding (class 2004)** with each attribute the class requires: the finding's uid and title, an analytic naming the Anomity policy, `severity_id`, `status_id` (new, or resolved when the finding is), the device, and product metadata. Guardrail decisions get an honest disposition: a deny is Blocked, a warn is Allowed because the action proceeded, and an ask is Other with a note that the user was prompted. Audit events do not get OCSF. The honest class is API Activity, which requires a structured actor, API operation and source endpoint that our audit events do not carry as fields. Filling them in would produce a record that passes validation and misleads, so audit records ship with a text body and the flat attributes. ## How delivery works Events go into a durable outbox, kept separate from every other SIEM destination's so that nothing done to one can delete another's backlog. A drain runs every minute, in batches of up to 500 records and 1 MB, gzipped. The outbox stores the neutral event and renders the OTLP record at delivery time, so an encoding fix also improves events already queued. Collector answers What Anomity does 200 Deletes the rows and counts them as forwarded 200 with a partial success Never retried, as the OTLP specification requires. Accepted and rejected counts and the collector's message are shown on the card 401 or 403 Marks the card **Reconnect needed** and keeps events queued for up to seven days 429, 502, 503, 504, other 5xx, timeout Retried on the next drain, honouring `Retry-After` up to fifteen minutes, for up to ten attempts Other 4xx Retrying identical bytes cannot succeed, so the batch is dropped and counted on the card 3xx Never followed Delivery is **at least once**. The OTLP specification is explicit that a client cannot know whether an unacknowledged request arrived, so a retry can duplicate, and `anomity.event_id` lets you dedupe. There is deliberately **no periodic health check**: proving a collector is alive would mean posting synthetic events into your SIEM all day, and a collector accepting a heartbeat says nothing about whether it exports onward. The card shows the last real delivery instead. ## How setup works - Run an OpenTelemetry Collector with an OTLP/HTTP receiver, reachable from the internet over TLS, and an exporter to your SIEM. - In Anomity, open Settings, Integrations, OpenTelemetry (OTLP) and enter the full logs URL. It must be HTTPS, with no credentials, query string or fragment in it, since the URL is shown on the card. A bare origin gets the standard /v1/logs path appended. - Add the headers your collector authenticates with, such as an Authorization bearer token. Up to ten are allowed, and zero is fine for a collector fenced by network policy alone. - Click Connect . Anomity sends a real, clearly labelled test record and stores the install only if the collector accepts it, so a dead endpoint never persists as a silently stopped feed. Header values are **write-only**: encrypted with AES-256-GCM as one blob, never returned by any endpoint, never logged and never written to the audit trail. The card shows header names only. Because this is the first SIEM path where the customer chooses the whole host, the connection is guarded on both sides: private and internal addresses are refused when you connect and again before every send, each connection is pinned to the address that was validated, which defeats DNS rebinding, and redirects are never followed. One endpoint per organization is the model; a customer who wants a SIEM and a data lake fans out in the collector. ## Current limits The encoder was built against the OTLP 1.11.0 specification and the OCSF 1.3.0 schema, and is covered by unit tests on both. What remains is what only real collectors can prove, and we would rather name it: - Live round trips. Every event family has to round-trip through a real collector, and the OCSF samples have to validate against the schema. - Per-SIEM routing notes for Splunk, Elastic, Sentinel, Google SecOps and security data lakes will be written from what we observe on live collectors, not guessed. - Egress IPs. A stable list of addresses to allow on your collector's firewall is not published yet. - JSON over HTTP only. Protobuf encoding comes when a customer needs to point straight at a vendor endpoint that rejects JSON. gRPC, mTLS client certificates and private connectivity are not in this release. - The per-family switches exist on the install but are not on the settings card yet. ## How Anomity and OpenTelemetry fit together Your SIEM correlates across every source it ingests; OpenTelemetry is how the agent layer now reaches it, whichever SIEM it is. Anomity supplies that layer: the Endpoint Sensor inventories agents, MCP servers, extensions, plugins, skills, secrets, hooks, CLIs and local LLM runtimes; the Browser Sensor covers AI web services and the accounts and secrets used in them; 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, and every deny becomes a record your SIEM can alert on. That is the runtime signal we described in [runtime monitoring and anomaly detection for AI agents](https://anomity.ai/blog/runtime-monitoring-anomaly-detection-ai-agents/), and the evidence trail from [how to audit AI agent activity](https://anomity.ai/blog/how-to-audit-ai-agent-activity/), delivered in a schema your SIEM already reads. If your SOC runs on Datadog, the [native Datadog Cloud SIEM integration](https://anomity.ai/blog/anomity-datadog-cloud-siem-integration/) keeps the feed in Datadog's own log shape, and [Rapid7 InsightIDR](https://anomity.ai/blog/anomity-rapid7-insightidr-integration/) has a native webhook path that carries the same OCSF object. Anomity collects metadata only, redacts secret values on the endpoint, and is SOC 2 Type II attested. To see your fleet's agent events flowing through your own collector, [book a 30-minute demo](https://anomity.ai/#early-access). Share: Copied ## Frequently asked questions What does the Anomity OpenTelemetry integration do? It sends Anomity's security events as OTLP log records to an endpoint you control, usually an OpenTelemetry Collector. The collector then exports them to your SIEM, data lake or both. The events are findings from the Endpoint Sensor, Browser Sensor and cloud discovery, audit events from the Anomity console, and guardrail decisions made at the agent hook. Why OpenTelemetry instead of a native integration for my SIEM? A native build per SIEM means a separate auth scheme, payload format, failure handling and settings card for every vendor. OTLP is an open, vendor-neutral wire protocol, and the OpenTelemetry Collector already knows how to export to most SIEMs and data lakes. One integration on our side, plus a collector on yours, covers far more destinations than we could build natively. Datadog Cloud SIEM and Rapid7 InsightIDR have their own native integrations as well. What is OCSF and why does Anomity use it? OCSF, the Open Cybersecurity Schema Framework, is an open schema for security events that many SIEMs and security data lakes read natively. OpenTelemetry defines no conventions for a security finding, so an OTLP record without a schema would carry field names only Anomity understands. Finding-shaped events therefore carry an OCSF 1.3.0 Detection Finding (class 2004) as the record body, with every attribute the class marks required. Why don't audit events get an OCSF body? The honest OCSF class for an audit event is API Activity, which requires a structured actor, API operation and source endpoint. Anomity's audit events do not carry those as structured fields today. Filling them in would produce a record that validates and misleads, so audit events ship with a plain text body plus the same flat attributes as every other record. Does a log level tell me how severe an event is? No, and you should not key detections on it. OTLP's severityNumber is a log level that collectors bucket by range. Anomity maps critical, high, medium, low and info into distinct ranges so ordering stays visible, but detection rules should key on the `anomity.severity` attribute or the OCSF `severity_id`, which carry the security severity exactly. What happens if my collector is down? Events wait in a durable outbox and are retried on the next one-minute drain. A 429, 502, 503 or 504 is retried with any `Retry-After` honoured, capped at fifteen minutes, and other 5xx responses are also retried up to ten attempts. A 401 or 403 marks the card 'Reconnect needed' and keeps events queued for up to seven days. A partial success is never retried, as the OTLP specification requires, and the rejected count is shown on the card. Can my collector sit on a private network? Not in this release. The endpoint must be reachable from the internet over HTTPS. Anomity refuses private and internal addresses, pins each connection to the address it validated, and never follows a redirect, because a redirect could carry your auth header to another host. Private connectivity and mTLS client certificates are not part of this release. What is still to come for the OpenTelemetry integration? At launch the encoder was built and tested against the OTLP 1.11.0 specification and the OCSF 1.3.0 schema, and the remaining work is about real collectors. Next, we want every event family round-tripped through a live collector, the OCSF samples validated against the schema, per-SIEM routing notes written from what we observe, and a stable egress IP list published so customers can firewall their collector. ## Related posts [Company ### Anomity Integrates with Datadog Cloud SIEM Anomity now forwards AI agent findings, audit events and guardrail decisions to Datadog Cloud SIEM, with a versioned schema and a durable outbox. Anomity Research · Aug 31, 2026 · 7 min](https://anomity.ai/blog/anomity-datadog-cloud-siem-integration/) [Company ### Anomity Now Forwards to Rapid7 InsightIDR Anomity now streams AI agent findings, audit events and guardrail decisions into Rapid7 InsightIDR Log Search, ready for rules that open investigations. Anomity Research · Oct 11, 2026 · 7 min](https://anomity.ai/blog/anomity-rapid7-insightidr-integration/) [Company ### Anomity Integrates with Google Chat Anomity now posts AI agent findings and digests to Google Chat spaces as cards, linked to your org by a one-time claim code rather than an email domain. Anomity Research · Sep 11, 2026 · 5 min](https://anomity.ai/blog/anomity-google-chat-integration/) ## Structured data ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Anomity Now Forwards Security Events over OpenTelemetry", "description": "Anomity now streams AI agent findings, audit events and guardrail decisions over OTLP to your OpenTelemetry Collector, with OCSF Detection Finding bodies.", "datePublished": "2026-09-24", "dateModified": "2026-09-24", "author": { "@type": "Person", "name": "Anomity Research", "jobTitle": "Anomity Research" }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/anomity-logo.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/anomity-opentelemetry-siem-integration/", "relatedLink": [ "https://anomity.ai/blog/anomity-datadog-cloud-siem-integration/", "https://anomity.ai/blog/anomity-rapid7-insightidr-integration/", "https://anomity.ai/blog/anomity-google-chat-integration/" ] }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/anomity-opentelemetry-siem-integration.png", "width": 1200, "height": 630 }, "articleSection": "Company", "wordCount": 1590, "timeRequired": "PT8M", "inLanguage": "en", "url": "https://anomity.ai/blog/anomity-opentelemetry-siem-integration/", "keywords": "OpenTelemetry SIEM integration for AI security events, OpenTelemetry, OTLP, OCSF, SIEM, Integrations, Security Operations, Detection Engineering" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What does the Anomity OpenTelemetry integration do?", "acceptedAnswer": { "@type": "Answer", "text": "It sends Anomity's security events as OTLP log records to an endpoint you control, usually an OpenTelemetry Collector. The collector then exports them to your SIEM, data lake or both. The events are findings from the Endpoint Sensor, Browser Sensor and cloud discovery, audit events from the Anomity console, and guardrail decisions made at the agent hook." } }, { "@type": "Question", "name": "Why OpenTelemetry instead of a native integration for my SIEM?", "acceptedAnswer": { "@type": "Answer", "text": "A native build per SIEM means a separate auth scheme, payload format, failure handling and settings card for every vendor. OTLP is an open, vendor-neutral wire protocol, and the OpenTelemetry Collector already knows how to export to most SIEMs and data lakes. One integration on our side, plus a collector on yours, covers far more destinations than we could build natively. Datadog Cloud SIEM and Rapid7 InsightIDR have their own native integrations as well." } }, { "@type": "Question", "name": "What is OCSF and why does Anomity use it?", "acceptedAnswer": { "@type": "Answer", "text": "OCSF, the Open Cybersecurity Schema Framework, is an open schema for security events that many SIEMs and security data lakes read natively. OpenTelemetry defines no conventions for a security finding, so an OTLP record without a schema would carry field names only Anomity understands. Finding-shaped events therefore carry an OCSF 1.3.0 Detection Finding (class 2004) as the record body, with every attribute the class marks required." } }, { "@type": "Question", "name": "Why don't audit events get an OCSF body?", "acceptedAnswer": { "@type": "Answer", "text": "The honest OCSF class for an audit event is API Activity, which requires a structured actor, API operation and source endpoint. Anomity's audit events do not carry those as structured fields today. Filling them in would produce a record that validates and misleads, so audit events ship with a plain text body plus the same flat attributes as every other record." } }, { "@type": "Question", "name": "Does a log level tell me how severe an event is?", "acceptedAnswer": { "@type": "Answer", "text": "No, and you should not key detections on it. OTLP's severityNumber is a log level that collectors bucket by range. Anomity maps critical, high, medium, low and info into distinct ranges so ordering stays visible, but detection rules should key on the `anomity.severity` attribute or the OCSF `severity_id`, which carry the security severity exactly." } }, { "@type": "Question", "name": "What happens if my collector is down?", "acceptedAnswer": { "@type": "Answer", "text": "Events wait in a durable outbox and are retried on the next one-minute drain. A 429, 502, 503 or 504 is retried with any `Retry-After` honoured, capped at fifteen minutes, and other 5xx responses are also retried up to ten attempts. A 401 or 403 marks the card 'Reconnect needed' and keeps events queued for up to seven days. A partial success is never retried, as the OTLP specification requires, and the rejected count is shown on the card." } }, { "@type": "Question", "name": "Can my collector sit on a private network?", "acceptedAnswer": { "@type": "Answer", "text": "Not in this release. The endpoint must be reachable from the internet over HTTPS. Anomity refuses private and internal addresses, pins each connection to the address it validated, and never follows a redirect, because a redirect could carry your auth header to another host. Private connectivity and mTLS client certificates are not part of this release." } }, { "@type": "Question", "name": "What is still to come for the OpenTelemetry integration?", "acceptedAnswer": { "@type": "Answer", "text": "At launch the encoder was built and tested against the OTLP 1.11.0 specification and the OCSF 1.3.0 schema, and the remaining work is about real collectors. Next, we want every event family round-tripped through a live collector, the OCSF samples validated against the schema, per-SIEM routing notes written from what we observe, and a stable egress IP list published so customers can firewall their collector." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "Anomity Now Forwards Security Events over OpenTelemetry", "item": "https://anomity.ai/blog/anomity-opentelemetry-siem-integration/" } ] } ```