--- title: "Anomity Now Forwards to Rapid7 InsightIDR | Anomity Blog" description: "Anomity now streams AI agent findings, audit events and guardrail decisions into Rapid7 InsightIDR Log Search, ready for rules that open investigations." url: "https://anomity.ai/blog/anomity-rapid7-insightidr-integration/" source: html --- Anomity Now Forwards to Rapid7 InsightIDR Contents - Why Rapid7 InsightIDR, and why now - What arrives in InsightIDR - The webhook URL is the credential - How delivery works - How setup works - Current limits - How Anomity and Rapid7 fit together - Frequently asked questions 0% 7 min read Share - X.com - LinkedIn - Email - Copy URL - Copy markdown [← Back to blog](https://anomity.ai/blog/) - Home - Blog - Anomity Now Forwards to Rapid7 InsightIDR ![Anomity robot illustrating Anomity Now Forwards to Rapid7 InsightIDR] Company # Anomity Now Forwards to Rapid7 InsightIDR Anomity Research Anomity Research · Oct 11, 2026 · 7 min read Share: Copied TL;DR - Anomity now forwards security events to Rapid7 InsightIDR . Create a Custom Logs event source with the Webhook collection method, paste its URL into Anomity, and findings, audit events and guardrail decisions stream into Log Search . - A Custom Detection Rule over those events, with the rule action set to create investigations, turns the findings that matter into InsightIDR investigations next to the rest of your SOC's work. Your SOC decides what becomes an investigation, in the tool where it already tunes detections. - Each event is flat JSON with top-level keys such as event_type , severity and policy_type , built for Log Search queries, plus the same OCSF Detection Finding object the OpenTelemetry integration emits. - No API key is involved. The webhook URL can only write logs to one event source, so Anomity treats it as the credential: encrypted, never displayed, never returned, and pinned to Rapid7's domain. - Delivery runs through a durable outbox drained every minute. A dead or replaced URL keeps events queued for up to seven days, and pasting the new URL delivers the backlog. - The integration follows Rapid7's published webhook and API documentation, and a handful of details are still being confirmed on live tenants. Anomity now forwards to **Rapid7 InsightIDR**. Create a Custom Logs event source in InsightIDR, paste its webhook URL into Anomity, and findings, console audit events and guardrail decisions stream into **Log Search** in near real time. A Custom Detection Rule over them turns the ones that matter into InsightIDR **investigations**. The integration is available today from the Rapid7 InsightIDR card under Settings, Integrations. This post covers what arrives in InsightIDR, why investigations come from your detection rule rather than from us, how the webhook URL is protected, and what is still being confirmed. ## Why Rapid7 InsightIDR, and why now Customers running their SOC on InsightIDR asked for one thing in particular: Anomity findings as investigations, next to everything else the team works. The question was how to get there. The direct route, creating investigations through the InsightIDR API, needs a **user API key**, and a user key can read and change the whole InsightIDR tenant. We took the other route. Anomity sends every event into Log Search through a webhook that can only write logs, and InsightIDR's own detection engine decides which events become investigations. That has three effects we like: - Your SOC decides what becomes an investigation , in the tool where it already tunes every other detection. Anomity sends everything; InsightIDR selects. - No API key changes hands. The webhook URL writes to one event source and nothing else. - The raw events stay searchable. Everything Anomity saw is in Log Search, including what never became an investigation, which is what you want during incident response when the question is what else the agent did. Like the [Datadog Cloud SIEM](https://anomity.ai/blog/anomity-datadog-cloud-siem-integration/) and [OpenTelemetry](https://anomity.ai/blog/anomity-opentelemetry-siem-integration/) destinations, this is a firehose rather than a notification rule: every event is queued before any rule matching, because a SIEM does its own filtering. Notification rules stay for people, in channels like [Slack](https://anomity.ai/blog/anomity-slack-app-integration/). ## What arrives in InsightIDR Three families of events, each with a switch on the install and all on by default: **findings** (policy violations; MCP servers, skills and AI tools seen for the first time on the fleet; AI applications found by cloud discovery), **console audit events**, and **guardrail decisions** (deny, warn or ask at the agent hook). Only events after you connect are forwarded. Each event is one flat JSON object: ``` { "timestamp": "2026-10-11T12:00:00.000Z", "source": "anomity", "schema_version": 1, "event_type": "violation", "severity": "high", "severity_id": 4, "policy_name": "Unattended agent session (runtime bypass)", "policy_type": "runtime_bypass", "finding_id": "", "device_id": "", "hostname": "eng-laptop-042", "event_id": "", "tenant_id": "", "message": "Claude Code session ran without permission prompts", "ocsf": { "class_uid": 2004, "...": "the OCSF Detection Finding" } } ``` Key On Use it for `event_type` every event `violation`, `hook`, `audit`, `new_mcp`, `new_skill`, `new_agent`, `discovered_app`, or `connection_test` for the test event `severity`, `severity_id` every event Anomity's own word, and the OCSF number from 1 to 5 `policy_type` violations **The primary detection discriminator**: scope a rule to the policies your SOC owns `hook_decision` guardrail decisions `deny`, `warn` or `ask` `audit_action` audit events Which console change was made `hostname`, `device_id` when known Pivot to the machine, and from there to your other telemetry `event_id` every event Deduplication, since delivery is at least once `ocsf` finding-shaped events An OCSF 1.3.0 Detection Finding, identical to the OpenTelemetry body Three decisions sit behind that shape. Keys are **flat and top-level**, because Log Search turns a JSON entry into key and value pairs and a detection rule is a query over those keys; a prefix would only lengthen every query. The keys are **the OpenTelemetry attribute names without their prefix**, derived in code, so the two destinations cannot drift into two vocabularies, and one `schema_version` versions both. And the field set is **the same allowlist** every Anomity SIEM destination publishes: nothing new leaves the platform for InsightIDR. InsightIDR caps a single webhook event at 100,000 characters. Messages are already capped at 4,000; if an event would still exceed 90,000, the `ocsf` object is dropped first and the message trimmed after it, and the event is marked `truncated` so you can tell. ## The webhook URL is the credential InsightIDR authenticates a Custom Logs webhook by a token in the URL's path. There is no header to keep a secret in, so the URL itself is the secret, and we handle it like one: - Encrypted at rest with AES-256-GCM. Only the host and the URL's last four characters are kept in the clear, which is all the card shows. - Never returned by any endpoint, masked or otherwise, and entered in a password field so it is not left on screen or in autofill history. - Never echoed. An authentication error carries no response text, every error is scrubbed of the URL's path, and the audit trail names the host only. - Pinned to Rapid7. The URL must be HTTPS on a subdomain of rapid7.com, on the standard port, with a path and no credentials or fragment. That makes this an InsightIDR integration rather than a second free-text webhook, and it removes the class of attack where a customer-chosen host points us at an internal address. - Redirects are never followed , because a redirect off a URL that carries a token is exactly the request that must not be made. - Re-checked before every send. A stored URL that fails the check is treated as needing reconnection, never as a reason to drop events. ## How delivery works Events wait in a durable outbox of their own, separate from the other SIEM destinations so that disconnecting one can never delete another's backlog. A drain runs every minute, sending JSON arrays of up to 500 events and 1 MB, a tenth of the webhook's documented request limit. InsightIDR answers What Anomity does 2xx Deletes the rows and counts them as forwarded 401, 403 or 404 Marks the card **Reconnect needed** and keeps events queued for up to seven days. A 404 usually means the event source was deleted or its URL regenerated 429, 5xx, timeout Retried on the next drain, honouring `Retry-After` up to fifteen minutes, for up to ten attempts Other 4xx or 3xx Dropped, counted and shown on the card; redirects are never followed **Reconnecting keeps the queue.** When the card says Reconnect needed, its **Replace webhook URL** control is already open. Paste the event source's current URL and Anomity test-sends to it, swaps it in place only if the test lands, and drains the queued events to it on the next tick. Disconnecting is the other way out, and it discards the queue; the confirmation says so. Delivery is at least once, and `event_id` lets a search or rule dedupe. ## How setup works - In InsightIDR, open Data Collection and add a Custom Logs event source. Name it Anomity, set the collection method to Webhook , leave the JSON event key empty so each element of the array becomes its own event, and copy the webhook URL it generates. - In Anomity, open Settings, Integrations, Rapid7 InsightIDR , paste the URL and click Connect . Anomity sends a labelled test event and saves the install only if InsightIDR accepts it, so a dead URL never persists as a silently stopped feed. The test event appears in Log Search within a minute or two; a new event source can show as unhealthy briefly while it initialises. - In Log Search , select the Anomity log and query for what your SOC should investigate, for example violations at critical or high severity. Narrow with policy_type to the policies your team owns, or with hook_decision for guardrail denials. - Create a Custom Detection Rule from that query and set its action to create investigations. Starting the rule in a preview mode for a few days is a sensible way to size the volume first. There is deliberately **no periodic health check**: it would post synthetic events into your SIEM all day. The card's health is the last real delivery. ## Current limits The integration follows Rapid7's published webhook documentation and API specifications. A few details can only be confirmed on a live tenant, and we would rather list them: - The webhook URL shape. The host pin accepts any subdomain of rapid7.com for now, and tightens once live tenants show the exact shape. - Delivery semantics. The success status code, how a JSON array splits into events with no event key set, and whether a deleted event source's URL always answers 404. - Investigations end to end. That a Custom Detection Rule over Custom Logs data opens an investigation, and the exact query syntax the card suggests. - No compression yet. Batches are sent uncompressed; at 1 MB a batch gains little from it. - Not in this release: creating investigations directly through the InsightIDR API, auto-creating the detection rule, reading anything back from InsightIDR, backfill, and per-customer field selection. The per-family switches exist on the install but are not on the card yet. ## How Anomity and Rapid7 fit together InsightIDR is where your SOC detects, investigates and closes out incidents across every source it collects. Anomity supplies the AI agent layer those sources do not see: 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, as described in [how Claude Code hooks work](https://anomity.ai/blog/how-claude-code-hooks-work/), and each denial is now an event your detection rules can act on. It is the structured trail our [guide to AI agent audit trails](https://anomity.ai/blog/ai-agent-audit-trail-and-logging-guide/) argues for, in the place your analysts already look. For a finding that needs an owner rather than an investigation, a notification rule can open a ticket in [Jira](https://anomity.ai/blog/anomity-jira-integration/) instead. Anomity collects metadata only, redacts secret values on the endpoint, and is SOC 2 Type II attested. To see your fleet's agent findings in your own InsightIDR tenant, [book a 30-minute demo](https://anomity.ai/#early-access). Share: Copied ## Frequently asked questions What does the Anomity Rapid7 InsightIDR integration do? It forwards Anomity's security events to an InsightIDR Custom Logs event source through its webhook. The events arrive as Log Search entries: findings from the Endpoint Sensor, Browser Sensor and cloud discovery, audit events from the Anomity console, and guardrail decisions made at the agent hook. A Custom Detection Rule over them can then open InsightIDR investigations. Does Anomity create InsightIDR investigations directly? Not in this release. Investigations are created by InsightIDR's own detection engine, from a Custom Detection Rule you write over the Anomity events. That is deliberate: your SOC decides what becomes an investigation in the tool where it already tunes every other detection, and the integration needs no InsightIDR API key, which could read and change the whole tenant. Creating investigations directly through the InsightIDR API is a possible later step. What does an event look like? Each event is a flat JSON object with top-level keys: `timestamp`, `source` (always `anomity`), `schema_version`, `event_type`, `severity`, `severity_id`, `policy_name`, `message`, `event_id`, `tenant_id`, and depending on the event `policy_type`, `finding_id`, `hook_decision`, `audit_action`, `pii_tier`, `finding_status`, `device_id` and `hostname`. Finding-shaped events also carry an `ocsf` object, an OCSF 1.3.0 Detection Finding. How is the webhook URL protected? The URL carries its own token, so it is the credential. Anomity stores the whole URL encrypted with AES-256-GCM, takes it in a password field, and never returns it from any endpoint, masked or otherwise. The card shows only the host and the last four characters. Error messages are scrubbed of the URL's path, the audit trail names the host only, and the URL is re-validated before every send. Why is the URL restricted to rapid7.com? Pinning the host to Rapid7's domain makes this an InsightIDR integration rather than a second free-text webhook, and it removes the class of attack where a customer-chosen host points Anomity at an internal address. Redirects are never followed, because a redirect off a URL that carries a token is exactly the request that must not be made. For an endpoint of your choosing, use the OpenTelemetry integration instead. What happens if InsightIDR rejects events or the event source is deleted? A 401, 403 or 404 marks the card 'Reconnect needed' and keeps the events queued for up to seven days; a 404 usually means the event source was deleted or its URL regenerated. The card's Replace webhook URL control test-sends the new URL and swaps it in place, and the queued events drain to it on the next minute. Rate limits and server errors are retried, honouring Retry-After, for up to ten attempts. Other rejections drop the batch and show the count on the card. Can I get duplicate events? Occasionally, yes. Delivery is at least once: if a batch was accepted but the acknowledgement never arrived, the retry sends it again. Every event carries an `event_id` that stays the same across retries, so a search or a detection rule can deduplicate on it. What is still being confirmed for the Rapid7 integration? It was built from Rapid7's published webhook documentation and API specifications, and a few details can only be confirmed on live tenants: the exact webhook URL shape, which may let the host pin tighten from Rapid7's whole domain, the success status code, how a JSON array splits into events, whether a deleted source's URL always answers 404, the query syntax shown on the card, and the full path from a detection rule on Custom Logs data to a new investigation. Each is being confirmed on live tenants. ## Related posts [Company ### Anomity Now Forwards Security Events over OpenTelemetry Anomity now streams AI agent findings, audit events and guardrail decisions over OTLP to your OpenTelemetry Collector, with OCSF Detection Finding bodies. Anomity Research · Sep 24, 2026 · 8 min](https://anomity.ai/blog/anomity-opentelemetry-siem-integration/) [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 Integrates with Zendesk Anomity now opens Zendesk tickets for AI security findings as internal notes, over OAuth client credentials, and solves or reopens them as findings change. Anomity Research · Sep 10, 2026 · 6 min](https://anomity.ai/blog/anomity-zendesk-integration/) ## Structured data ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Anomity Now Forwards to Rapid7 InsightIDR", "description": "Anomity now streams AI agent findings, audit events and guardrail decisions into Rapid7 InsightIDR Log Search, ready for rules that open investigations.", "datePublished": "2026-10-11", "dateModified": "2026-10-11", "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-rapid7-insightidr-integration/", "relatedLink": [ "https://anomity.ai/blog/anomity-opentelemetry-siem-integration/", "https://anomity.ai/blog/anomity-datadog-cloud-siem-integration/", "https://anomity.ai/blog/anomity-zendesk-integration/" ] }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/anomity-rapid7-insightidr-integration.png", "width": 1200, "height": 630 }, "articleSection": "Company", "wordCount": 1464, "timeRequired": "PT7M", "inLanguage": "en", "url": "https://anomity.ai/blog/anomity-rapid7-insightidr-integration/", "keywords": "Rapid7 InsightIDR integration for AI agent findings, Rapid7, InsightIDR, SIEM, OCSF, Integrations, Security Operations, Incident Response" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What does the Anomity Rapid7 InsightIDR integration do?", "acceptedAnswer": { "@type": "Answer", "text": "It forwards Anomity's security events to an InsightIDR Custom Logs event source through its webhook. The events arrive as Log Search entries: findings from the Endpoint Sensor, Browser Sensor and cloud discovery, audit events from the Anomity console, and guardrail decisions made at the agent hook. A Custom Detection Rule over them can then open InsightIDR investigations." } }, { "@type": "Question", "name": "Does Anomity create InsightIDR investigations directly?", "acceptedAnswer": { "@type": "Answer", "text": "Not in this release. Investigations are created by InsightIDR's own detection engine, from a Custom Detection Rule you write over the Anomity events. That is deliberate: your SOC decides what becomes an investigation in the tool where it already tunes every other detection, and the integration needs no InsightIDR API key, which could read and change the whole tenant. Creating investigations directly through the InsightIDR API is a possible later step." } }, { "@type": "Question", "name": "What does an event look like?", "acceptedAnswer": { "@type": "Answer", "text": "Each event is a flat JSON object with top-level keys: `timestamp`, `source` (always `anomity`), `schema_version`, `event_type`, `severity`, `severity_id`, `policy_name`, `message`, `event_id`, `tenant_id`, and depending on the event `policy_type`, `finding_id`, `hook_decision`, `audit_action`, `pii_tier`, `finding_status`, `device_id` and `hostname`. Finding-shaped events also carry an `ocsf` object, an OCSF 1.3.0 Detection Finding." } }, { "@type": "Question", "name": "How is the webhook URL protected?", "acceptedAnswer": { "@type": "Answer", "text": "The URL carries its own token, so it is the credential. Anomity stores the whole URL encrypted with AES-256-GCM, takes it in a password field, and never returns it from any endpoint, masked or otherwise. The card shows only the host and the last four characters. Error messages are scrubbed of the URL's path, the audit trail names the host only, and the URL is re-validated before every send." } }, { "@type": "Question", "name": "Why is the URL restricted to rapid7.com?", "acceptedAnswer": { "@type": "Answer", "text": "Pinning the host to Rapid7's domain makes this an InsightIDR integration rather than a second free-text webhook, and it removes the class of attack where a customer-chosen host points Anomity at an internal address. Redirects are never followed, because a redirect off a URL that carries a token is exactly the request that must not be made. For an endpoint of your choosing, use the OpenTelemetry integration instead." } }, { "@type": "Question", "name": "What happens if InsightIDR rejects events or the event source is deleted?", "acceptedAnswer": { "@type": "Answer", "text": "A 401, 403 or 404 marks the card 'Reconnect needed' and keeps the events queued for up to seven days; a 404 usually means the event source was deleted or its URL regenerated. The card's Replace webhook URL control test-sends the new URL and swaps it in place, and the queued events drain to it on the next minute. Rate limits and server errors are retried, honouring Retry-After, for up to ten attempts. Other rejections drop the batch and show the count on the card." } }, { "@type": "Question", "name": "Can I get duplicate events?", "acceptedAnswer": { "@type": "Answer", "text": "Occasionally, yes. Delivery is at least once: if a batch was accepted but the acknowledgement never arrived, the retry sends it again. Every event carries an `event_id` that stays the same across retries, so a search or a detection rule can deduplicate on it." } }, { "@type": "Question", "name": "What is still being confirmed for the Rapid7 integration?", "acceptedAnswer": { "@type": "Answer", "text": "It was built from Rapid7's published webhook documentation and API specifications, and a few details can only be confirmed on live tenants: the exact webhook URL shape, which may let the host pin tighten from Rapid7's whole domain, the success status code, how a JSON array splits into events, whether a deleted source's URL always answers 404, the query syntax shown on the card, and the full path from a detection rule on Custom Logs data to a new investigation. Each is being confirmed on live tenants." } } ] } ``` ```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 to Rapid7 InsightIDR", "item": "https://anomity.ai/blog/anomity-rapid7-insightidr-integration/" } ] } ```