SIEM cost control, run by agents

Key takeaways

• •The problem today. SIEM cost follows log volume, and volume grows faster than the security budget. Debug logging, duplicate feeds and sources nobody queries sit in the same bill as the sources your detections depend on.
• •What changes. Agents attribute the ingest bill to each source, flag the noisy, duplicated and unused ones, and propose routing low-value telemetry to cheaper storage, with dependent detections listed.
• •What stays with your people. Any change that touches a detection-relevant source, and anything that drops data rather than reroutes it. The security lead approves each one.
• •The result. A smaller ingest bill at the next renewal, and a record showing no detection lost its data.

The problem today

Splunk cost, Sentinel cost and a security data lake bill all trace back to one number: how much you send. A release ships debug logging. Two forwarders deliver the same firewall events. A vendor adds fields to every record and nobody reads them. Finance asks the security data team why the bill moved.

Answering takes a week of exporting volume by source and asking detection engineers which rules use what. The safe choice is to cut nothing, so log volume keeps growing and the budget fight happens at renewal with no evidence.

The data platform teams that own this sit in the security and observability telemetry and data platform and fleet data groups.

What changes with Data Workers

Agents treat ingest as a cost line with an owner for every source. Each source is priced, tied to the team or release behind it, and checked for repeats and readers. A source nobody queries, or one that arrives twice, becomes a proposal; a source a detection reads becomes a proposal with that detection named. The same question applies to the observability bill and to a Splunk estate you keep.

The workflow, step by step

1. 1.The Usage Intelligence agent calls detect_usage_anomalies and flags sources whose volume jumped or arrived twice, each priced in ingest cost and tied to the team or release behind it.
2. 2.The Data Context & Catalog agent calls analyze_query_history and finds the sources and fields that no search, dashboard or hunt reads, in the lake and the systems connected to it.
3. 3.The same agent calls blast_radius_analysis and lists the detections, reports and downstream tables that depend on each candidate source, so the risk is visible before anyone decides. Detection engineering confirms any dependency the agent cannot see.
4. 4.The Data Access & Governance agent calls request_governance_review and sends each proposal to its named approver. The Cost Savings & Data Cleanup agent drafts the routing change, such as sending a verbose source to cheaper storage, and the Autonomous Data-Conductor coordinates the sequence within the autonomy each domain allows.

The same method on warehouse tables: unused tables and idle warehouses, and the Cost Savings & Data Cleanup agent.

The impact metrics we move

• •Ingest bill attributed to source and owner: from about 3 days to about 30 min
• •Volume spike traced to its source: from about 3 days to under 1 h
• •Duplicate feeds found: from about 2 days to about 1 h
• •Unused sources and fields listed: from about 1 week to about 2 h
• •Detection dependencies mapped for a source: from about 2 days to about 1 h
• •Routing proposal with evidence ready for review: from about 3 days to about 1 h

What goes on autopilot

• •The weekly cost attribution. Ingest is priced by source, team and release, so the renewal conversation starts from a report, not an export.
• •Spike and duplicate alerts. A debug-logging release or a doubled feed reaches the owning team the same day, with volume and cost attached. Nothing is rerouted without an approver.
• •The unused-source and field list. It refreshes continuously, so candidates wait for the security lead.

Where your people stay in charge

The security lead approves every change that touches a detection-relevant source. Cheaper storage can be less useful: in Microsoft's own guidance for its Sentinel data lake, analytics rules do not run on data held only in the lake tier, so moving the wrong source silently ends the alert. Keeping those feeds healthy is the job of detection data quality.

Anything that drops data rather than reroutes it also goes to a named approver, because dropped events cannot be replayed. So do sources under a retention obligation. Agents show the affected detections and the way back, and a person decides. Each approval and result lands in a tamper-evident audit trail you can export. Everything starts at L1, observing only, and autonomy rises only on evidence.

The pilot

• •Scope. Cost attribution and noisy, duplicate and unused source detection on your top 20 sources by volume.
• •First week. Agents run at L1, observing only, and show the routing changes they would have proposed and the detections each would affect, with receipts.
• •By week two. The routine attribution and alerts run on their own; anything touching a detection-relevant source stays with the security lead.
• •At day 30. We review the impact metrics against your baseline:

• •Volume spike traced to its source: from about 3 days to under 1 h
• •Unused sources and fields listed: from about 1 week to about 2 h

• •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.