AI SOC: what changes when security operations can act?

A security alert suggests that an engineering account has been compromised. The account can reach a workstation used to maintain a production line. The SOC has enough evidence to take the threat seriously, and the tools to revoke access immediately.

Should it?

Before answering, I'd want to know what that account is doing, which services depend on it, whether an engineer is carrying out authorised work, and what happens if access disappears halfway through. I'd also want to know what the attacker could do while we deliberate.

This is an illustrative scenario, but it captures the question I think deserves more attention in the AI SOC discussion. Once a security system can act, we need to understand the consequences of its decisions as carefully as we understand the threat.

The outcome we're after is a business that can keep operating securely. Faster investigation and response matter because they help achieve that outcome. Their value depends on what the system actually does.

What is an AI SOC?

An AI SOC is a security operations centre that uses AI to support or perform tasks such as alert triage, investigation, threat hunting and response. The term covers several operating models, from assistants that help analysts interpret evidence to agents that use tools and carry out defined actions.

For this discussion, an agentic SOC means one in which AI can choose and sequence investigative steps or actions within an authorised scope. That scope matters. Permission to query an identity platform is quite different from permission to disable an account.

These capabilities can help with a familiar problem: useful evidence is spread across systems, while analysts have limited time to gather it, assess it and decide what to do. AI can assist with that work. Whether it does so reliably needs to be tested against the tasks and conditions it will encounter.

My view is that an effective AI SOC develops through the same disciplines that make any SOC effective: understanding the organisation, maintaining useful evidence, agreeing responsibilities and learning from outcomes. AI changes what we can delegate and how quickly work can happen. It also creates new things to evaluate and govern.

The foundations still matter

There is already a recognisable evolution argument in the market. Bridewell, for example, describes integrating agentic capabilities into existing security operations, with autonomous containment or human validation chosen according to the organisation's requirements. This isn't an entirely new way of thinking about a SOC. Bridewell's Agentic SOC approach.

The more interesting question is how an organisation earns confidence in each additional capability.

A team might be ready to automate evidence collection across several tools while still requiring review of its conclusions. It might allow a narrowly defined response for a well-understood endpoint incident, but require an operational owner to approve a similar action in a production environment.

Both can be sensible choices within the same SOC. A single label such as “autonomous” tells us very little about those boundaries.

I'd assess maturity at the level of the task, the evidence available and the consequence of getting it wrong. That gives us a more useful conversation than asking what percentage of the SOC we can automate.

Business context has to influence the decision

Knowing that an asset is “critical” is a start. It doesn't tell us which response is appropriate.

Consider the engineering account in the opening example. To make a useful decision, the SOC may need to understand its owner, privileges, current sessions, maintenance activity and the systems it can reach. It also needs to distinguish an individual engineer's account from an identity used by an application or shared operational process.

Some of that knowledge may live in an identity platform or asset inventory. Some may be held by an operational team. Getting it into a form that a security workflow can use is part of the engineering work.

Freshness matters too. Yesterday's approved maintenance window cannot justify today's unexplained activity. An asset owner who changed roles six months ago may no longer be the right person to authorise a response.

For each important piece of context, I'd want to know where it came from, when it was last checked and what the workflow should do if it is missing or conflicts with another source. If the answer is simply that the agent will work it out, we haven't finished designing the process.

A malicious verdict does not settle the response

There are two judgements here: how strong the evidence of compromise is, and which intervention is appropriate.

The first informs the second, but it doesn't complete it. A high-confidence detection can still lead to a poorly chosen action if the system misunderstands a dependency or exceeds its authority.

Microsoft's automatic attack disruption documentation offers a concrete example of controls around automated action. It describes correlated signals, detector validation, supported containment actions, exclusions and the ability to reverse actions. Those are product-specific capabilities, but they illustrate the range of considerations involved. Microsoft Defender automatic attack disruption.

For an AI SOC, I would make the response boundary explicit:

These questions should shape the workflow before an incident. They are difficult to resolve for the first time while an attacker is moving through the environment.

Unified IT/OT makes the trade-offs visible

A unified IT/OT SOC should help people understand threats that cross technical and organisational boundaries. It should bring together the evidence needed to follow an incident from an enterprise identity or remote-access service towards an operational asset.

That does not mean applying the same response policy everywhere.

In our example, the team might consider revoking a specific session, restricting remote access, changing a network rule or isolating the engineering workstation. Each option needs to be assessed against the actual environment. Even an apparently narrow identity action could interrupt a legitimate dependency.

The operational team contributes knowledge about the process and the consequences of intervention. The security team contributes evidence about the compromise, likely progression and available controls. The response depends on both.

This is where I find the maturity argument most useful. A mature SOC has worked through these relationships, agreed who can authorise what and rehearsed the difficult cases. AI can help it use that preparation quickly. Where the preparation is incomplete, the workflow needs a defined way to handle uncertainty.

Can we test the intervention before we need it?

This leads to a further question: could we model the attack path and test candidate changes before deploying them?

Claroty and Frenos announced a partnership in July 2026 covering environment-specific digital twins, attack simulation, segmentation validation and remediation prioritisation in industrial environments. The announcement is a useful example of the direction of travel, although the stated benefits remain vendor claims. Claroty and Frenos partnership announcement.

The wider IT/OT opportunity is to connect identity, access, network and operational dependencies so that new intelligence can be assessed against the environment we actually have.

For example, a report of a newly exploited weakness might prompt a review of affected technology, attacker prerequisites and routes towards an important service. Candidate interventions could then be compared within the model.

We need to be precise about what such a test establishes. An attack-path model may show that a proposed rule blocks a represented route. Demonstrating that the production process will remain healthy requires the relevant operational behaviour and dependencies to be represented and validated too.

A model can provide useful evidence while still having blind spots. Its assumptions, age and coverage belong alongside its conclusions.

Planned remediation gives us time for more extensive testing. During a live incident, the SOC may need to use a previously validated action within agreed limits. The design should account for both situations, rather than assuming every response can wait for a fresh simulation.

What should we measure?

Speed is useful, but I would want to see it alongside the quality and consequences of the work.

Did the investigation reach a conclusion supported by the evidence? Did it identify an important uncertainty? Was the proposed response within scope? Did it reduce the attacker's access? Did it cause an avoidable interruption? When the system escalated, did it give the next person enough information to make a decision?

These are also good questions for an evaluation programme. Tests should include missing telemetry, stale ownership information, legitimate activity that resembles an attack and situations where the normal approver is unavailable.

Choosing to escalate can be the correct outcome. It can also introduce a dangerous delay. We need to assess that trade-off against the scenario, rather than rewarding either action or abstention automatically.

An investigation that produces a persuasive explanation is only part of what we're evaluating. We also need to establish whether its evidence is sound and whether its proposed action is appropriate.

Start with one decision worth improving

For a team considering its next AI SOC capability, I'd start with a recurring decision that is difficult or slow today. Define the outcome you want to improve, the evidence required, the actions that might follow and the limits of the system's authority.

Then test it. Include the awkward cases. Involve the people responsible for the affected service. Use the findings to decide whether the workflow is ready for assistance, supervised execution or a bounded automatic action.

That gives the organisation a practical route towards greater capability, with evidence for each step.

The AI SOC I want to see is one that can explain why an intervention is justified, understand what it might affect and demonstrate whether it achieved the intended outcome. Its authority to act should grow with the quality of that evidence.

I've been exploring these questions through an AI SOC demonstration in my Playground. It uses a simulated IT/OT scenario to make the investigation and response decisions tangible.

Explore the AI SOC demo in the Playground. As you work through it, consider whether you would make the same response decision and what additional evidence you would want. I'd welcome your feedback, particularly where your own operational experience would lead you to a different conclusion.