Blog Beyond agentic SOC
Blog · AI in security operations
Beyond agentic: why SOC autonomy must get cheaper as it learns
Agentic AI has become the next promise in security operations: a model that plans an investigation, calls the tools and writes the conclusion. It is a real step forward. It is also a stepping stone, because the way most agentic tools are built makes them more expensive, less predictable and no wiser the longer they run.
What “agentic SOC” usually means
Most agentic SOC tools follow the same pattern. An alert arrives. A large general-purpose model, usually a frontier model hosted by a third party, receives the alert and a list of tools it may call: search the SIEM, look up an IP address, query the EDR, check a user’s recent logins. The model decides which tool to call, reads the result, decides on the next call, and repeats until it is ready to write a summary or a verdict.
This is a genuine improvement on a chat copilot. The model does part of the investigation instead of only describing the alert. But the architecture has consequences that become visible only at SOC scale, over months rather than in a demo.
Five weaknesses that grow with scale
Dependence on a third-party model
The quality, price, availability and behaviour of your SOC depend on a model you do not control. A model update can change outcomes overnight, and an outage or rate limit stops the work.
Token cost that multiplies
Every step sends the growing context back to the model. Retries, self-checks and reflection loops each add another round. One investigation can cost many times what a single summary costs.
Unpredictable latency
A chain of remote calls, each waiting on a shared service, takes as long as it takes. The slowest investigations are often the complex ones that matter most.
Non-determinism that is hard to audit
Run the same alert twice and the agent may take a different path and reach a different answer. Explaining to an auditor why a case was closed becomes difficult.
Fragility when tools change
Agents depend on tool descriptions and data schemas. When a field is renamed or an API changes, an agent can keep running and quietly draw the wrong conclusion.
You pay twice
The visible cost of an agentic SOC is the model bill: tokens in and tokens out for every step of every investigation. The less visible cost is everything needed to run agents reliably at scale. That means inference capacity, whether rented in the cloud or run on GPUs you own, plus orchestration to manage many concurrent agent runs, plus monitoring to catch loops, failures and runaway spend.
Both costs track alert volume. More data sources, more customers for a managed provider, or a noisy week all mean more agent runs. The cost curve goes up with the business, which is the opposite of what automation is supposed to do. A team that adopts an agentic tool to save analyst time can find itself managing a second budget that grows just as fast as the first.
Agents rarely learn your environment
The most important limitation is not cost. It is that most agent runs start mostly from scratch. The agent that investigated a backup job yesterday does not remember that this job runs every night on that server. The lesson an analyst gave when correcting a verdict is not turned into a lasting change. Prompt instructions and retrieved notes help, but they are not the same as a system that has verifiably improved on your data.
A security team gets better over time because it accumulates experience about its own environment. An automation layer that does not accumulate experience will keep making the same mistakes at the same cost, no matter how capable the underlying model is.
Agentic tooling compared with learning autonomy
| Question | Typical agentic tool | Learning autonomous SOC |
|---|---|---|
| Where does the reasoning run? | Mostly in a third-party frontier model | Mostly in compact models on your own infrastructure |
| How does cost behave as volume grows? | Rises with every alert and every step | Falls per case as more work is handled locally |
| What happens after a case is settled? | Little; the next run starts afresh | The outcome becomes a verified improvement |
| Can the result be audited? | Hard; paths vary between runs | Each conclusion is tied to recorded evidence |
| Where does the data go? | To the model provider | It stays with you by default |
What lasting autonomy looks like
Autonomy that lasts has a different cost curve. Routine work, which is most of a SOC’s volume, is handled by compact models that are specialised for each task and adapted to the customer’s environment, running on the customer’s own infrastructure. Large-model reasoning is still useful for the rare hard case, but it becomes an occasional, policy-controlled resource rather than the engine behind every alert, and what it contributes is turned into local capability.
Learning has to be part of the loop. When a case is settled, by a person or by the evidence, the outcome should make the next similar case faster and more accurate. Improvements should be verified before they are trusted, and a system should be able to show that it has not become worse at catching real attacks while becoming better at closing noise.
Trust is earned in steps. A learning SOC works alongside analysts first, its conclusions are compared with theirs, and autonomy is widened one capability at a time when the evidence supports it. Response remains proposal-first: a person approves each action, and every step is recorded.
The direction ApexAI takes
ApexAI is built on this view. Its models run locally by default, its use of external large models is optional and governed by your policy, and it keeps learning from your own settled cases. The result we aim for is an autonomous SOC whose cost does not grow linearly with tokens and whose quality improves the longer it runs. The Why ApexAI page sets out the wider problem and our answer.
Questions
Is agentic AI bad for security operations?
No. Agentic tools are a real step beyond chat copilots. The problem is relying on them as the destination: cost, latency, auditability and learning all get harder at SOC scale when every step depends on a third-party frontier model.
Why does agentic SOC cost grow with alert volume?
Each alert triggers an agent run, and each run makes several model calls with growing context, plus retries and checks. More alerts mean proportionally more calls, and the infrastructure to run them grows too.
How can an autonomous SOC get cheaper over time?
By handling routine work with compact local models adapted to your environment, using large models only occasionally under policy, and turning settled outcomes into verified improvements so more cases are handled locally.
See ApexAI on your own alerts.
A walkthrough with your team, in observe mode first: ApexAI scores and proposes, nothing acts on its own.