We built an AI SOC and deliberately gave it no write access
Published
An AI SOC should investigate automatically and act only with human approval. Investigation is reversible: if the AI is wrong, you have lost a few minutes of reading. Containment is not: isolating the wrong host or disabling the wrong account creates an outage you own. The honest design is to automate the reading and keep a person on the decision that changes your environment.
What does "autonomous SOC" actually mean in a product demo?
In most demos, "autonomous" means the tool reaches a verdict on an alert without a human, and then takes an action, such as isolating a device, disabling an account or closing the case. The demo works because the scenario is chosen. The alert is unambiguous, the telemetry is complete, and the right answer is known in advance.
The interesting question is not what the tool does when it is right. It is what happens when it is wrong, on an alert nobody rehearsed, at 3am, with a gap in the logs. That case is where the cost of autonomy actually lands, and it is the case a demo never shows you.
This matters because the category is crowded and the language has drifted. "Autonomous", "agentic" and "AI analyst" are used to describe everything from a genuinely capable investigation engine to a scripted playbook with a language model bolted to the summary field. The word tells you almost nothing about the design underneath.
Why is a wrong action so much more expensive than a wrong verdict?
The two failure modes are not symmetric, and the asymmetry is the whole argument.
If an AI investigation is wrong, a human reads a wrong conclusion. If the reasoning is shown, the human catches it, disagrees, and moves on. The cost is a few minutes and some trust. The damage is bounded and recoverable.
If an AI action is wrong, something in your estate changes. A finance workstation is isolated during month-end close. A service account is disabled and a payment run fails. A domain controller is quarantined. Now you are running an incident that you caused, at the time of day you had the least cover, and the tool that caused it is the one you were relying on to tell you what happened.
The second failure is also harder to notice. A confident, wrong verdict that closes a case silently is worse than an uncertain one that gets escalated, because nobody ever looks at it again. Automation converts an error into a decision that no human reviews.
Where is automation genuinely safe, and where is it not?
The useful line is not "AI good, AI bad". It is reversibility and blast radius. Sort every candidate action by what it costs to undo, and the safe set becomes obvious.
- Safe to automate: reading logs, correlating events across sources, resolving entities, mapping to MITRE ATT&CK, drafting a timeline, proposing a verdict. Nothing changes; a human can check the work.
- Reasonable to automate with a granted scope and an audit trail: reversible containment such as revoking a session or blocking an indicator, where undo is one click and the record shows who approved it.
- Not safe to automate: anything irreversible or high blast radius, such as disabling a privileged account, isolating a critical host, or deleting data. The cost of being wrong is an outage, and the tool cannot judge your business context.
- Never safe to automate: closing a case as benign with no human ever seeing it. That is not efficiency, it is a silent unreviewed decision, and it is exactly the failure an auditor will find later.
What does OwlSOC do instead?
OwlSOC connects read-only to Microsoft Sentinel, Microsoft Defender and AWS Security Hub, and investigates each alert automatically. It produces an evidence-linked timeline where every claim carries a source or pivot ID back to the origin log, a MITRE ATT&CK mapping, the resolved entities, and a plain-language verdict, typically in under two minutes.
The verdict is deliberately hedged: "likely true positive", "likely false positive", or "uncertain — needs review". It recommends containment actions but does not perform them. Execution only happens through a write connector after a human approves, and only if the tenant granted that specific write scope. Reversible actions can be undone; the few that cannot be reversed are flagged and require an explicit extra confirmation before they run.
That is a design choice, not a missing feature. We would rather be the tool that hands a security lead a defensible decision at 3am than the tool that made an undefensible one on their behalf.
How do you pressure-test an autonomy claim before you buy?
The claims are unfalsifiable from the outside, so ask questions whose answers are checkable. A vendor who has thought about this will answer them quickly and specifically. A vendor who has not will change the subject to accuracy percentages.
- What permissions do you request on day one, and what is the exact role or scope? If the answer is write access before you have any trust, ask why.
- Show me an investigation where the tool was wrong. What did the output look like, and what would have happened if autonomy had been enabled?
- Which specific actions execute without a human, and which cannot? Is that list configurable per action, or is it a single on/off switch?
- When it acts, what is the undo path, how long does it take, and is the undo itself audited?
- What does the tool do when the evidence is incomplete? If it never returns "uncertain", ask what happens to the alerts that genuinely are uncertain.
- Can I read the reasoning back to the raw log for every claim, or only a score?
Is restraint just a slower product?
It is slower in exactly one place: the moment a human reads the recommendation and clicks approve. Everything before that, which is the part that actually consumes analyst hours, is already automatic.
Alert triage is not slow because approving an action is slow. It is slow because someone has to pull the logs, work out what happened, decide whether it matters, and write it down. That is the work worth automating, and it is the work that is safe to automate, because a person still reads the answer before anything changes.
The industry is currently selling the opposite trade: automate the decision, keep the human for the reading. We think that has it backwards, and we would rather say so plainly than ship an autonomy toggle we would not switch on in our own estate.
Frequently asked
Should an AI SOC be allowed to contain threats automatically?
For most teams, no, at least not initially. Automated investigation is low risk because a wrong conclusion only costs a human a few minutes of reading. Automated containment is high risk because a wrong action, such as isolating a critical host or disabling a service account, creates an outage you caused. A safer model is to automate the investigation, recommend the action, and require a human approval before anything changes, with reversible actions preferred and irreversible ones flagged.
What is the difference between an AI-assisted and an autonomous SOC?
An AI-assisted SOC uses AI to do the investigation work and then presents a verdict and a recommendation to a human, who decides. An autonomous SOC additionally lets the AI take action, such as containing a host or closing a case, without a human in the loop. The distinction that matters commercially is not the label but the permissions: ask what write access the tool requests and which specific actions it can execute unattended.
Does OwlSOC take actions automatically?
No. OwlSOC investigates and recommends. A human on your team approves any action that touches your environment, and execution only runs through a write connector on the write scopes you have explicitly granted, which the API enforces. Reversible actions can be undone in one click, and the few actions that cannot be reversed are flagged and require an explicit extra confirmation before they run.
Why does OwlSOC hedge its verdicts instead of giving a definite answer?
Because a definite answer would often be false. OwlSOC returns "likely true positive", "likely false positive" or "uncertain — needs review", which reflects what the evidence actually supports. An engine that is never unsure is either working on unusually clean data or is concealing its uncertainty, and concealed uncertainty is what produces confident wrong closures that no one ever revisits.
Is read-only access enough to investigate an alert properly?
Yes. Investigation is a reading problem: pulling the alert, the surrounding logs, and the identity, device and network signals needed to reconstruct what happened. All of that is available read-only. Write access is only required to change something, which is the step that should require a human decision anyway, so it can be granted later, narrowly, and per action.
Start with a 30-day refundable pilot. £495, one environment, every alert investigated, a full report at week four. Read-only, live within 48 hours of access.