In one paragraph
When a hunting agent queries data where it already lives, the cost of each query lands on the platform that runs it, and the agent's read access becomes part of your attack surface. Scope and cost are best set before a trial starts: which sources, which fields, which time ranges, how often, and with what ceiling. Most vendor pages reviewed for this guide do not publish how query costs are controlled, so these are questions to ask rather than facts to look up.
By Autonomous Threat Hunting editors ·
Why does querying in place move the cost?
Several vendors in this guide's directory describe working on data where it is stored rather than copying it. In alphabetical order: Anvilogic describes "One query across Splunk, Snowflake, Sentinel, S3, and more, without moving the data." Artemis Security describes a split: "Hot-path data ingested, high-volume data queried where it lives." Mars Security says: "Hunt across every log source, cloud, and endpoint without moving a byte". Nebulock describes Helix federated search "to get data just-in-time, not just-in-case". Vega describes federated analytics with "No migration, ingestion, or egress."
Not copying data avoids a second store and a second retention clock. It also means each query an agent runs is executed by the data platform, whether a SIEM, a warehouse or object storage, and metered under that platform's own terms. A person hunting by hand runs a limited number of queries in a day. An agent that hunts continuously can run many more, including at hours when no one is watching. The data platform's pricing model, not only the hunting tool's licence, then shapes the total cost.
Anvilogic publishes a calculator that estimates data-lake compute and storage, and states that its savings figures do not include Anvilogic annual licensing. It is a reminder that compute on the data platform and the hunting tool's licence are separate lines in a budget. In this guide's directory, the public pages reviewed for Anvilogic, Cotool, Mars Security and Nebulock did not describe query cost controls. That does not mean the controls are absent, only that a buyer has to ask.
What drives query cost in an agentic hunt?
- Frequency: how often continuous hunts run, and whether each new piece of intelligence starts a new set of queries.
- Time range: a retrohunt or backtest over weeks of history reads far more data than a check of the last hour. Mars Security, for example, states that each new rule is backtested against 30 days of the customer's own data.
- Breadth: one hypothesis may be tested across endpoint, identity, cloud and network sources, so one hunt can mean several queries on several platforms.
- Query shape: broad scans without field or time filters usually cost more than narrow lookups on indexed fields.
- Corroboration: checking a hit against other sources is valuable, and it also adds queries.
- Retries and exploration: an agent that rewrites a failed query, or follows a lead step by step, may run many variations before it reports.
None of these is a reason to avoid autonomous hunting. They are the inputs to a budget.
How should you scope what an agent may read?
Data scope is a security question as much as a cost one. A hunting agent usually needs read access to sensitive platforms: identity logs, endpoint telemetry, cloud audit trails. That access could itself be abused, and the risks page treats it as one of the three main risks.
- Give the agent a dedicated service identity on each data platform, not a shared analyst account, so its queries are attributable and its access can be revoked on its own.
- Grant read-only access, limited to the indexes, tables or buckets the agreed hunts need, following least privilege. Add sources deliberately rather than starting with everything.
- Decide which fields the agent should not see, such as message bodies or personal data, and check whether the platform can mask them at query time.
- Keep the data platform's own query log on for the agent's identity, so you can review what it ran without relying on the vendor's report.
- Write down where results go. A finding may contain raw log lines; ask where the vendor stores them, for how long, and who can read them.
What controls should you ask for before a trial?
- A query budget per platform: a ceiling on queries, data scanned or compute per day, and what the system does when it reaches it.
- Time-range limits by hunt type, so continuous hunts look at recent data and longer retrohunts need a person to start them.
- Scheduling, so heavy hunts can run when the data platform is least busy.
- An estimate or dry-run mode that shows the queries and their expected scope before they run.
- Per-hunt reporting of the exact queries, the platforms they ran on and the time range, which is also what a reviewer needs to judge a result.
- A way to pause all hunting on one platform without stopping the rest.
Then measure. In a trial, compare the data platform's own usage report for the agent's identity with the vendor's account of what ran, and ask about any difference. The checklist includes questions on data access and cost that fit alongside these.
Where does the SIEM fit?
In this model the SIEM stays what it is: one of the data platforms the agent reads from, alongside data lakes, warehouses and tool APIs, with its retention, compliance and alerting jobs unchanged. The questions above apply to each platform the agent is allowed to query, and the answers can differ from one platform to the next.
Sources
- Anvilogic, home page anvilogic.com
- Anvilogic, calculator anvilogic.com
- Artemis Security, platform overview artemissecurity.com
- Mars Security, home page marssec.ai
- Mars Security launch announcement, Security Boulevard securityboulevard.com
- Nebulock, platform nebulock.io
- Vega, home page vega.io