Most “AI SOC” is one model writing a nicer summary of an alert nobody had time to read. Here is the other approach: a team of specialized agents that scope the question, pull context out of every system you run, the SIEM included, argue the verdict, and hand a human something worth signing.
A senior analyst does not investigate an alert by reading it more carefully. They go and find out things the alert does not contain. Is this host actually important? Is that account a service principal or a human? Did this person resign last week? Only then does the alert mean anything.
That is the work: a sequence of narrow questions, each answered by whoever knows how to ask the right system in the right language. A single summary, or one large prompt, cannot do it. So that is how we built it.
THE SHORT VERSION
- An investigation runs as a team of specialized agents working across nine narrow stages.
- Agents delegate to sub-agents that own one system each, across 500+ typed tools and ~1,000 investigation playbooks. In production today that means SIEM, EDR, identity and cloud, with HR, CMDB and change management next.
- Connectors are typed and read-only against your systems, scoped to one customer. The only thing an agent writes to is our own incident record.
- A verdict must clear an evidence gate, then survive a challenger agent whose only job is to break it.
- An agent reads attacker-authored text all day. Injection is contained by architecture.
See how the UnderDefense Agentic AI SOC investigates, triages, and resolves real alerts.
Nine stages, each with a narrow job
Each stage is a distinct agent with its own instructions, its own tool set, and no authority beyond it. Narrow agents are testable, debuggable, and, as we will come to, much harder to weaponize. The sequence is in Figure 1; four of the stages are worth explaining properly.
- Intake is deliberately not an agent. Normalization, deduplication, grouping and threat-intelligence enrichment run before any model is involved, so the agents reason over structured evidence anchored to facts a model did not invent.
- The Scoping Agent decides what question is actually being asked: which attack technique this maps to, which investigation playbook applies, and what would count as evidence either way. It does not improvise what to check. It is handed a methodology, drawn from a library of roughly a thousand investigation playbooks built and refined against real casework. That is what makes two investigations of the same technique comparable, and what makes a bad one diagnosable.
- The Context Agent builds the picture the alert is missing: who this identity is, what this asset is, who owns it, what it normally does. This is the stage that reaches outside security tooling entirely, and it is the subject of the next section.
- The Challenger Agent reads the finished verdict and tries to destroy it. What benign explanation fits this evidence equally well? Which claim rests on a single observation? What was never checked? Disagreement between it and the adjudicating agent is itself a signal: it routes the incident straight to a human.
- The Response Agent proposes containment options with their blast radius attached: isolate this host and these services go down; disable this account and this integration breaks. It proposes. A person approves.
Agents that call agents, across every system you run
Here is a real shape of alert: a user moved several gigabytes to personal cloud storage overnight. Your SIEM can tell you it happened. It cannot tell you the thing that decides the verdict.
Ask your directory: is this a privileged account, which groups did it join last month? Ask your HR system: is this person still employed, did they resign nine days ago, are they a contractor whose engagement ends Friday? Ask your asset inventory: is this laptop corporate or personal, is it managed? Ask your ticketing system: is there an approved migration request that explains all of this?
Same telemetry. “Resigned nine days ago” and “on an approved data migration” are not the same incident.
No single agent can be good at all of that. Each of those systems has its own query language, its own permission model, its own undocumented quirks, and its own idea of what an “identity” is. So the Context Agent does not query them. It delegates: it states the question, “is this identity privileged, and has its group membership changed recently?”, and a sub-agent that owns that integration decides how to answer it in the system’s own terms.
That is the reason breadth is achievable at all. Adding a new system means writing one sub-agent that understands one product; nothing upstream changes. The Context Agent never learns a new query language. It learns that a new kind of question can now be answered. That is how an investigation reaches across identity, endpoint management, cloud, code repositories, collaboration platforms, HR and business systems without any of it being hardcoded into the reasoning.
Today that reach covers the security estate: directory and identity, endpoint, SIEM, and cloud audit. The HR, asset-inventory, and change-management sub-agents are the next ones in. Worth saying plainly, because the roster is what a buyer should ask any AI SOC vendor to enumerate: the interesting question is not how many logos sit on the integrations page, but how many distinct questions an agent can actually pose mid-investigation. On our side that is over five hundred individual tools, each one a specific, typed operation against a specific system.
There is a hard-won principle underneath this. A model can know a query language perfectly and still have no idea where your data lives: index names, field names, and schemas are local, undocumented, and different in every environment. So the system never guesses them. Sub-agents discover what a tenant actually has, record it, and match against it on every subsequent investigation. It goes and looks, which is exactly what a good analyst does on their first week at a new account.
It is also where access control lives. No agent talks to a customer system directly; every sub-agent runs through a connector we build and audit, exposing a fixed set of read operations, scoped to one customer at a layer the model cannot reach. And when a sub-agent cannot answer because a system is unconnected, unlicensed, or does not retain the data, that gap is reported openly. It is never silently skipped. An investigation that quietly ignored the endpoint fleet because the data was missing is far more dangerous than one that says so.
The same alert, finished
So: same alert, same night, after the agents have been round it. Almost nothing below was in the alert that arrived. Four systems were queried to assemble it: directory, identity, endpoint, and cloud audit. Every one of those queries was chosen by an agent deciding what it needed to know next.
Three things in there matter more than the verdict itself. The baseline block is not decoration. The agent had to establish what normal looks like for this account before it was permitted to call anything malicious. The gap line is a first-class output: email and DLP were not available, the investigation says so, and the challenger used exactly that to cap the confidence. And the rule-outs are specific: each one names the evidence that killed it. None of them simply gestures at “no benign explanation found”.
Note also what the agent never had to be told. Nobody wrote a rule saying “a recent Finance-Admins addition plus a re-registered MFA device plus an unmanaged host is suspicious”. Those three facts came from three different systems, and the value is in having asked for them at all.
The AI SOC agent reads whatever the attacker wrote
Look back at that evidence block. Command lines, file names, cloud domains, process names: a large share of what an investigation agent reads is authored, at least partly, by the person being investigated. This is the job description. And a model cannot reliably separate data it should analyze from instructions hidden inside that data, so anyone selling a classifier that catches injection is selling a permanent arms race with a fixed win condition for the attacker.
We treat it as a containment problem instead. Untrusted content is never concatenated into an agent’s instructions. It arrives as tool output, in a delimited channel, and the raw records are stripped out again before the next model call, so what travels onward through the pipeline is a structured finding, with the log text already stripped out. The agents that touch that content are the ones with the least authority in the system: they hold query tools and nothing else. There is no shell, no arbitrary network access, no file write, and no path to publish a verdict. Which customer’s data is in scope is set by the layer underneath the model and cannot be reached from inside a prompt.
That stripping is a real trade-off, and it deserves to be named plainly. A downstream agent reasoning over a summarized finding has less to work with than one holding the full result set, and there are investigations where a detail that looked irrelevant when the finding was written would have mattered later. We accept that cost, and pay some of it back by letting the adjudicating agent pull a raw result when it needs to quote evidence. Anyone who tells you their isolation layer is free has not measured it.
The output side gets the same treatment, which is the half people forget. The escalation text an agent writes is read by an analyst in a console, pasted into a customer email, and increasingly parsed by whatever automation sits downstream. Agent-generated text is rendered as untrusted data everywhere it lands as a result. No live markup, no auto-followed links, no interpretation of instruction-shaped strings by the next system in the chain. An investigation summary is evidence about an attacker. It is never a message from one.
Assume an injected instruction can influence an agent. The useful question is what that buys the attacker: one more read-only query, in the same customer’s scope, inside a bounded iteration budget, followed by a challenger agent and a human who both see an investigation that went somewhere strange. That is a very different posture from an agent holding a shell, write access to your ticketing system, and the authority to quarantine a host. Injection is not impossible to trigger. The outcomes worth having stay unreachable regardless.
And we do not take that on faith. UnderDefense has run offensive security and red team engagements for years, against other people’s systems and our own; the tenant isolation boundary, the connector surface, and the agent tool permissions are treated as targets by the same people who break into things for customers. Testing that the UnderDefense Agentic AI SOC cannot be talked across a tenant boundary is not a side project here. It is the day job, pointed inward.
A verdict has to earn its confidence
Most AI triage fails review not because the model is wrong, but because it is confidently wrong in a way nobody can audit. So the reasoning discipline is enforced structurally. It is not simply requested politely in a prompt.
The most valuable rule: before an agent may call anything malicious, it has to have looked at what normal is for that host, that account, that process: weeks of history, never just the last hour. This kills the most common class of AI SOC error, calling something malicious because it looks unusual to a model that has never seen the baseline. Beyond that: coverage gaps cap confidence, every evidence item carries a reference, and an “alternatives ruled out” section is mandatory. There is also a counter-intuitive rule worth stealing: a benign verdict needs a higher bar than a true positive, because asserting nothing happened is a negative claim, and that is harder to prove than asserting something did.
Then we measure it against a corpus of real incidents. Anecdotes do not factor in. This is the part we are most confident about, because it was built before the agents were trusted with anything. Every run is fully traced, so any verdict can be reconstructed step by step months later. Senior analysts blind-test a random sample and feed corrections straight back into agent tuning. An automated judge runs the same incidents twice: once by the agent, once worked by hand, and scores them against each other on steps taken, sources consulted, queries chosen, and final verdict. And a set of real anonymized incidents with Tier-3 answers acts as a regression gate in CI: a prompt change or a new model has to prove it did not make things worse, or it does not ship. Unit tests, but for agents.
That program runs continuously and across more than one customer environment, which matters more than the raw count: an agent that looks excellent on one tenant’s data has usually learned that tenant. It has not learned the job.
Models, and why we refuse to be married to one
Model choice is tiered by what each stage needs. The stages doing multi-step reasoning with tool calls run on the current state-of-the-art frontier models from Anthropic; the high-volume structured generation over already-enriched input runs on the fast tier of the same family, where cost and latency matter more than reasoning depth. Both on managed enterprise inference, with regional deployment for data residency and no customer data used for training. We deliberately do not name a version here, because by the time you read this it will be the wrong one. The stages are pinned to a capability tier, and the tier is re-benchmarked against the regression set whenever a new model lands.
What matters more than which model tops the benchmark this quarter is that the orchestration is model-agnostic by design. Swapping the inference provider, or running entirely on self-hosted models inside a customer’s perimeter, is a configuration change. That is what makes air-gapped deployment possible, and why a model release next quarter simply becomes an upgrade.
Autonomy is a policy decision
An agent’s autonomy should depend on how much of that process you want automated. It does not depend on how capable the model happens to be. We map every SOC process to an explicit level and defend each one.
That table is the honest answer to “is your SOC run by AI?” No. Triage at machine speed runs under sampling QA, on a bounded tool surface, behind an evidence gate. Investigation is accelerated by it. Containment is run by people. Work that took an analyst 20 to 40 minutes of manual pivoting arrives as a reasoned verdict inside a sub-15-minute SLA, and the human reviewing it is the reason the whole thing is safe to run at all.
The interesting engineering in an AI SOC is not the model. It is everything you build to make the model’s mistakes cheap.
Anyone can put a language model in front of an alert queue. The work is in the boundaries: what each agent may touch, what it must prove before it may conclude, who challenges it, and who is accountable when it is wrong. Ask your vendor those four questions. The answers tell you more than the model name.
See how UnderDefense Agentic AI SOC resolves a real incident on your stack.
Related reading
- UnderDefense — MAXI AI SOC platform overview
- MITRE — ATT&CK, the technique taxonomy behind our investigation playbooks
- Anthropic — Model Context Protocol specification
- NIST — Cybersecurity Framework, the process map behind our autonomy levels
- OWASP — Top 10 for LLM Applications (LLM01: Prompt Injection)
1. How are AI SOC agents different from an AI feature bolted onto a SIEM?
An AI feature summarizes data the SIEM already surfaced. These agents decide what evidence would settle the question and go and get it, including from systems that are not security tools at all, like HR, asset inventory, and change management.
2. What access do the agents actually have to our systems?
Read-only, and never direct. Every call goes through connectors we build and audit, exposing a fixed set of read operations, scoped to one customer at a layer the model cannot override. There is no shell and no arbitrary network access. The only thing any agent writes to is our own incident record and the ticket. Nothing is ever written back into your environment.
3. Can an attacker prompt-inject your investigation agents?
Assume they can. Reading attacker-authored text is the job, and no filter reliably catches injection. Containment is architectural: untrusted content arrives as delimited tool output and is stripped before the next model call, the agents that read it hold query tools and nothing else, the operation set is fixed and read-only, customer scope is enforced below the model, and a challenger agent plus a human review anything that went somewhere strange.
4. How do you know the verdicts are any good?
A challenger agent attacks every verdict before a human sees it. Then three loops run over time: blind human sampling, an automated judge comparing agent work against analyst work on the same incidents, and a regression gate over curated real incidents that any prompt or model change must pass.
5. Do the agents take action on our environment?
No. They read, reason, and write to the incident record. Containment options are proposed with their blast radius; a person approves.
