Security data is distributed for good reasons. Endpoint telemetry lives in the EDR, identity logs may sit in the SIEM, and high-volume cloud data usually moves to a data lake or object storage because that's where the economics make sense. The problem is that analysts still have to work across all of it.

An investigation can mean asking the same question in multiple consoles, rewriting it in different query languages, and manually stitching the results together before the team can make a decision. That friction adds time to every investigation and makes the architecture underneath the SOC the analyst's problem.

Anvilogic's Federated Search removes that burden by letting teams search across the systems already holding their security data. For that to work, though, the integrations have to reflect where enterprise security data actually lives. That footprint has grown quickly. Since June, Anvilogic has added eight platforms, with SentinelOne as the newest addition.

Anvilogic + SentinelOne

Most teams already bring SentinelOne threats and cloud detection alerts into Anvilogic through the SentinelOne Alerts integration for detection, correlation, and triage. Federated Search closes the loop. When an alert needs more context, the host activity behind it is one query away, and the telemetry never leaves SentinelOne.

That matters because endpoint data is usually what turns an investigation from a suspicion into an answer: Which process spawned the binary? What did it write to the disk? Did the same parent process appear somewhere else? What was happening on the host before the alert fired? That evidence lives in SentinelOne, but the context needed to understand it might live somewhere else, like a SIEM or data lake, and without a connected workflow analysts have to move between consoles, rewrite the query, and bring the results back manually.

The Anvilogic-SentinelOne integration brings that endpoint data into the same Federated Search experience as the rest of the environment. Analysts can ask a question in plain language, and Federated Search generates the SentinelOne query alongside queries for every other connected repository. If they already know what they're looking for, they can write S1QL directly with syntax highlighting and autocomplete. The results come back together, with each result clearly labeled by source.

Setup is straightforward: customers create a Service User with the Viewer role in SentinelOne, generate an API token, and add that token and the console URL in Anvilogic. Access is read-only, queries run directly against the SentinelOne API, and only the results return to Anvilogic. Nothing is deployed into the SentinelOne environment, and the endpoint telemetry isn't ingested into another platform, so there's no second copy of the data to maintain or pay for.

New integrations since June

SentinelOne is the eighth platform Anvilogic has added since the beginning of the summer. Each addition expands the environments security teams can work across without forcing the data into one place first:

• CrowdStrike LogScale: Teams can search LogScale directly
• CrowdStrike NG-SIEM: Gives organizations using CrowdStrike another way to work across that environment from Anvilogic
• Elasticsearch: Supports Elastic Cloud, Serverless, and self-hosted 7.x and 8.x environments, with guided setup, automatic index discovery, and both natural-language and ES|QL querying
• OpenSearch: Extends the same reach to OpenSearch environments, including clusters where roles restrict access to specific indices
• Dynatrace: Makes observability data available to security workflows when the evidence needed for an investigation lives outside the traditional security stack
• ClickHouse: Gives teams using it as a cost-efficient data lake the ability to search directly in plain language or SQL
• Google SecOps: Can be queried using UDM Search, so analysts can work with the same syntax they already use in the Google SecOps console

And now SentinelOne adds endpoint activity through both S1QL and natural-language search. Together, those eight platforms expand on existing support for Splunk, Microsoft Sentinel, Snowflake, Databricks, and Amazon S3.

Anvilogic integrations are built the same way for a reason

The number of integrations matters, but the more important part is the pattern behind them. Any platform that exposes an API or query mechanism can be connected to Anvilogic and used from the same place as the rest of the environment.

• Search: the repository is connected with a read-only credential and queried in place using its native fields. Nothing is deployed in the source environment.
• Detect: everything in Search, plus scheduled detections. Anvilogic compiles normalization into the query at runtime, so detections use common field names and still require no footprint in the source platform.

Queries run where the data already lives, and only the results return to Anvilogic. Nothing is migrated, there's nothing new to deploy in the source environment, and teams don't have to build another ingestion pipeline before they can use the data. They're adding reach, not infrastructure. Where a repository exposes the necessary query APIs, new integrations are built toward Detect, so customers can move beyond search and run detection directly against the data as well.

Why it matters

Coverage should grow with the architecture, not force the architecture to change.

As Guang Wang, Sr. Director of Security Operations and Engineering at Alteryx, put it: "Anvilogic is the perfect solution because it doesn't depend on any specific underlying data lake or SIEM. It isolates and abstracts the layer of data storage down to the schema."

SAP approached the same problem from a different direction, maintaining Splunk while moving telemetry to Databricks and using Anvilogic to run detection across both. The underlying idea is the same: security operations shouldn't have to start over every time the data moves.

What’s up next

Observe and Corelight are currently in development, and Elasticsearch is moving toward Detect. Beyond those additions, the roadmap continues to be driven heavily by customer demand. When a platform exposes a query API, support can typically be added in two to three weeks.

That means a missing connector doesn’t have to become a reason to redesign the environment around the security platform. If you’re already an Anvilogic customer, the SentinelOne integration will be available under Settings → Integrations → Available.

If you’re not, book a demo and see how Anvilogic can work across the data and platforms you already use.