Most conversations about AI in security operations stop at "copilots" - assistants that summarise an alert so a human can action it faster. That was never the interesting end state. At a BaFin-regulated consumer neobank, and again at a high-growth UK home-services marketplace, we went further: a fleet of autonomous agents running the security operations centre itself. Every detection the SIEM raised - the platform that collects logs from across the estate and fires an alert when something matches a rule - was triaged, investigated and closed by an agent, or escalated with a finished investigation attached. It ran live in production for over six months, closed 95% of the workload without a human touching it, and produced zero false positives.

95%
Closed without a human
0
False positives
6+
Months live in production
Tier 1 + 2
Owned end to end

That covered both tiers of the traditional model: the first-line triage that decides whether an alert matters, and the second-line investigation that works out what actually happened. The 5% that reached a person was not the agents giving up. It was the set we deliberately reserved: live incidents, anything needing a judgement call about the business, and the deep investigations where a human should be the one deciding. Everything else - the volume that used to consume an entire shift pattern - closed itself, with the evidence written down.

This post is the honest version of that story: what actually made it work, what it did to the team, and what we would tell anyone starting the same journey this year.

What "autonomous" actually means here

The SIEM stayed where it was. What changed is what happened after it fired. Every detection was picked up by an agent that gathered its own context from across the estate, reasoned about consequence rather than signature, and then either closed the alert with its working shown or handed a finished investigation to a human.

The pipeline
One detection, four stages, then exactly one of two outcomes
01
Gather context first
Identity, device posture, recent activity, the ticket queue, the business system involved, and what this user and this host normally do.
02
Correlate, do not pattern match
Pull the related signals from every other source and assemble a timeline. One detection is rarely the story; the sequence around it is.
03
Reason about blast radius
Not 'is this detection suspicious' but 'if this were real, what is exposed, who is affected, and how far could it spread?'
04
Meet the gate
Evidence chain complete and confidence above threshold, or the alert stops being an automated decision.
Then exactly one of
Close it, with the working shown
Benign resolved and documented, or contained: isolate the endpoint, revoke the session, disable the account, pull the message tenant-wide. Every action logged with the evidence that justified it.
Escalate with the work attached
Never a naked 'please look at this': the full evidence chain, the timeline and a recommended action, readable in two minutes.
The gate is the whole design. An agent may only act where the evidence chain supports the action and confidence clears the threshold. Everything else leaves the automated path with the investigation already written.

That last point is the one most teams get wrong. Escalation quality is the product. A human should be able to read for two minutes and decide.

Why it was right every time

Zero false positives sounds like suppression. It was the opposite, and it was not luck either. It came from one thing: the agents were never asked to judge a detection on the detection alone.

A SIEM rule fires on a pattern. A human analyst is trusted because they go and look things up: who is this person, is that host meant to talk to that subnet, did we approve that change last Tuesday, is this IP in a feed we care about, have we seen this exact thing before and what did we decide. That lookup work is the whole job, and it is precisely what an agent with the right connections can do exhaustively, in seconds, on every single alert, without getting tired at 3am.

Context
What the agents could reach before they made a call
Identity and access
Who the user is, what they normally do, where they normally do it from, what they can reach, and whether any of that changed in the last hour.
Identity providerMFAprivileged accessHR joiners and leavers
Endpoint and infrastructure
Device posture and compliance state, running processes, the cloud platform's own admin layer, the network path, and what the affected system is actually connected to.
EDRdevice managementcloud platformnetwork
Business and change context
The ticket queue, the change record, the deployment that went out an hour ago, the asset inventory and the owner. Most alarming behaviour is somebody doing their job.
Ticketingchange managementCI/CDasset inventory
Threat intelligence
Multiple feeds, checked live rather than on a nightly sync: infrastructure reputation, active campaigns, malware families, and what is currently being exploited against organisations that look like this one.
Commercial feedsopen source intelsector sharingvendor telemetry
Memory and organisational rules
Every previous verdict and why it was reached, the exceptions the business has approved, the systems that are allowed to look strange, and the escalation rules written by the people accountable for them.
Case historyapproved exceptionspolicyrunbooks
Breadth is what removes false positives. An agent that can only see the alert guesses; an agent that can see the identity, the device, the change record, the intel and the last time this happened does not have to.

That last plane is the one nobody builds first and everybody wishes they had. Memory is what turns a good investigation into a consistent one. The same finding investigated in March and again in August reaches the same verdict for the same stated reasons, and when it does not, the difference is explainable. No human SOC achieves that, because no human SOC has the same people on shift in March and August.

Signal quality
What drove the queue before, and what drives it now
What the verdict rests on now
Behaviour in context: what this identity and this host normally do
The correlated timeline across every connected source, not the single detection
Live threat intelligence on the infrastructure and technique involved
Business criticality of the asset and the data it can reach
Organisational memory: what we decided last time, and the exceptions we approved
What stopped driving the queue
Raw SIEM rule severity taken at face value
Coverage-optimised vendor defaults that treat everything as urgent
Alert volume as a proxy for risk, and dashboards as a proxy for control
Re-ranking is not suppression. Nothing was hidden. The order changed, so the work a human saw was the work that could actually hurt.
The governing rule

AI proposes, guardrails decide. Agents investigate, reason and act inside a boundary somebody wrote down. Humans own the boundary, the exceptions and anything that is a live incident. Every automatic action is evidence-gated, and confidence below threshold escalates instead of guessing. There is no "the AI went rogue" story here, because the architecture makes the failure mode boring.

What it did to the team

This is the part people are least prepared for, and it is the biggest result.

When 95% of the queue closes itself, the analyst role stops existing. Not the people: the role. There is no longer a job that consists of reading alerts and deciding whether they matter, because that work is done, consistently, before anyone arrives. What remains is genuinely engineering: building and maintaining the integrations that give the agents their context, writing and improving detections, running live incidents, and designing the guardrails everything else operates inside.

The shift
Where the work went, and where the people went
What left the human day
Reading and triaging the alert queue
Manually gathering context from six consoles per investigation
Writing up findings that a machine had already reasoned through
Shift patterns designed around queue depth rather than value
What the same people now do
Detection engineering: building, tuning and testing what the SIEM looks for
Integration and platform work that widens what the agents can see
Live incident response and the judgement calls that belong to a person
Architecture, consulting into product teams, and building the next agent
Nobody was made redundant by this. The same people stopped doing the work a machine does better and started doing work that compounds.

Analysts became engineers, architects and internal consultants. That is a career path, not a redundancy notice, and it is worth saying plainly to a team before you start rather than after. The people who ran the queue are the people who understand the detections best; they are the obvious people to build the thing that replaces the queue.

The economics moved in the same direction. Headcount that used to scale with alert volume stopped scaling with it. Tooling bought purely to make a queue survivable stopped being necessary. Out-of-hours cover stopped being a rota problem. Cost came out across people, tools and infrastructure, and the spend that remained bought engineering rather than triage.

What surprised us

  • The SOC became a platform team. Once investigations were automated, the interesting work moved to building integrations and improving evidence quality. Hiring changed shape: we wanted engineers who could build, not analysts who could click.
  • Breadth of integration mattered more than model quality. Every accuracy problem we had traced back to something the agent could not see. Connecting one more system beat prompt engineering every time.
  • Humans stayed in the loop by design, not necessity. We kept named humans accountable for every category of decision. The agents made them dramatically more effective, not redundant.
  • The phishing mailbox was the perfect first agent. High volume, mostly benign, crisp verdict space. Our AI Security Mailbox investigates every reported email end to end, reaches a verdict, and removes confirmed threats organisation-wide in minutes. Borderline cases escalate with the full audit trail. If you are picking your first agentic use case in security, pick that one.

The principles we would hand you

Do this next
Five things to settle before an agent touches your alert queue
1Pick a bounded verdict space for the first agent - reported phishing, or one noisy high-volume detection - and refuse anything with lateral blast radius until that one has a track record.
2Connect the context before you tune the reasoning. An agent that cannot see your identity provider, your change records and your intel feeds will guess, and a guess is a false positive waiting to happen.
3Write down the evidence chain each automatic action requires, then enforce it in code. If the agent cannot show its work, it cannot act.
4Set an explicit confidence threshold and make escalation the default below it. A wrong escalation costs minutes; a wrong auto-action costs trust in the whole programme.
5Tell the team what this makes them before you build it. Analysts becoming engineers is the best outcome available, and it lands very differently if they hear it from you first.

Attack your own agents before you grant production trust: prompt injection in email bodies, poisoned intelligence, contradictory evidence, malformed data. Autonomy is earned, not configured. And name each agent, with a named human accountable for its decisions. Penny Pryce drafts procurement. Rex Reeves triages cloud issues. Larry Ledger runs lead disputes. Callum Chaser runs the executive cycle. The naming sounds like a gimmick until the first time someone in a review says "that was Rex" and the whole room knows who owns the answer.

Ask these
Questions that tell you whether you are ready
For our highest-volume detection, what share of investigations end in no action - and could we defend that number to an auditor?
How many systems would an agent need to reach to investigate that detection as well as our best analyst does?
If an agent isolated an endpoint at 03:00, could we reconstruct exactly which evidence justified it, six months later?
Which decisions would we never let an agent commit, and is that boundary written down or just assumed?
Is our escalation output good enough to decide from in two minutes, or does every escalation start a fresh investigation?
If the queue disappeared tomorrow, what would our analysts build - and have we told them that is the plan?

Where this goes next

The 2026-27 question is not whether security operations can run themselves. We have proven they can, in regulated environments, under BaFin-level scrutiny, with the evidence trail to show for it. The question is what a security team becomes when the queue is solved: smaller, more senior, embedded in engineering, and building agents rather than watching dashboards.

If you are standing at the start of that journey, that is exactly what we help teams with. Book an hour and bring your scariest operational problem.