Cybersecurity briefing
/
The AI SOC Still Needs a Chain of Command
A PwC survey finds just 22% of leaders would let AI act without approval. Why an AI SOC must separate investigating a threat from authority to respond.
/
AUTHOR
Jeff Dyer
/
SHARE THIS ARTICLE
Overview
Security leaders are drawing a line between letting artificial intelligence investigate an attack and letting it decide what to shut down. In October 9 reporting by The Wall Street Journal, that distinction emerged as a central concern for companies adopting autonomous cyber defenses. For organizations considering an AI-enabled security operations center, the consequential question is how much authority to delegate once an investigation reaches a conclusion.
The underlying PwC survey, published October 1, found that 22% would authorize AI agents to execute defensive actions without human approval. Another 38% would permit partial autonomy, while 36% preferred human-led execution supported by AI. The survey covered 3,934 business and technology leaders across 71 countries, with responses collected from May through July 2026. These are reported preferences, not a measurement of deployed systems or proof that autonomous response is unsafe.
The figures nevertheless put a practical problem into focus. An agent can produce a convincing explanation of suspicious activity before anyone has established whether the proposed response is acceptable to the business. The investigation and the authorization need separate scrutiny.
Containment can interrupt the business
Consider a hypothetical alert involving an administrator account and unusual activity on a server. An investigation might connect the login to a new location, identify unfamiliar processes and recommend isolating the host. Those findings help establish a security concern. They do not, by themselves, establish whether isolation would interrupt a critical application or disconnect people who need it.
In a hospital, a shared service may support clinical work. In manufacturing, the same action could affect production scheduling. A law firm might lose access to documents needed for a filing. These examples illustrate dependencies a response decision must consider; they are not accounts of specific incidents.
That does not make delay inherently safer. Leaving a compromised system connected can allow further damage. The operational choice requires someone to weigh the evidence against the consequences of acting and waiting. Automating the investigation can give that person a better starting point, provided the system also identifies missing evidence and uncertainty.
The authority should be defined for each action and target. Permission to query endpoint records need not include permission to isolate every endpoint. Permission to quarantine a confirmed malicious message need not include permission to suspend the sender's account. Treating all of those operations as one grant of autonomy obscures the decisions that carry different business risks.
Approval must include the proposed change
An approval request is useful when the reviewer can see what will change. A generic prompt to approve remediation leaves too much unstated. The reviewer needs the target, the specific operation, supporting evidence and relevant dependencies, along with the path for recovery if the action proves mistaken.
AI SOC platforms are beginning to separate the work of investigating a threat from the authority to respond to it. One example is 7AI, which uses AI agents to gather evidence from an organization's existing security tools and carry an investigation through to a proposed response.
A security team can delegate that investigative work while retaining approval over consequential actions, such as isolating a production server. Its response controls connect those approvals to execution through the underlying security tools, with an audit trail of what was authorized and performed. That lets an organization expand automation selectively, according to the systems involved and the consequences of acting. The available actions depend on the specific integration and permissions configured.
Operational policy still has to supply the conditions. An approval should apply to the identified system and proposed action, with a defined period of validity. If new evidence changes the target or expands the scope, the earlier decision may no longer be appropriate. A person approving one workstation's isolation has not necessarily approved a subsequent action against a shared server.
The same discipline matters when response is preauthorized. A repeatable action can be automated within tested conditions, with an exception path when those conditions fail. The organization needs to decide who receives that exception and what happens if nobody is immediately available to resolve it.
A completed request is not a verified response
The distinction continues after execution. A tool may acknowledge an isolation request before the device applies it. A credential change may require additional checks to determine whether relevant access has actually ended. A workflow can complete one step and fail at the next.
An incident record therefore needs to distinguish the request from its observed result. Where possible, the executing system should provide confirmation of the changed state. If confirmation is unavailable, the case should retain that uncertainty rather than present the action as complete.
Repeating a failed operation also deserves scrutiny. Retrying a query is different from repeating a destructive change whose first result is unknown. The response design needs a way to reconcile ambiguous outcomes before proceeding, particularly when several tools are participating in the same incident.
This is where an AI deployment becomes an engineering and operating-model project. Someone must own connector permissions, failure handling and the evidence needed to close a case. Those responsibilities persist even when the agent prepares the investigation and coordinates the work.
Expand autonomy through operational testing
The useful starting point is a bounded workflow with a clear owner. Historical cases can help teams examine whether an agent gathers relevant evidence, recognizes conflicting signals and recommends an action consistent with the organization's response procedures. Controlled exercises can then test the approval and execution path without exposing critical systems to an untested change.
Evaluation should include cases where the correct response is to escalate or gather more information. A system that always reaches a confident answer may be less useful than one that identifies when the available records cannot support a decision. Teams also need to test what happens when a connector loses access, an approver is unavailable or an action succeeds only partly.
Speed and reduced analyst effort matter, but they are incomplete measures. The organization also needs to know whether the right target was selected, whether the action was authorized and whether its outcome was verified. Additional autonomy becomes defensible when those conditions hold in the workflow being considered.
For companies evaluating an AI SOC, the immediate task is to identify a response process they can test end to end. Define who may authorize each consequential change, preserve the evidence behind the decision and verify the result in the system that performs it. That gives security teams a practical basis for delegating more work while retaining accountability for the business consequences.
/
BLOG
Other insights
Cybersecurity briefing
/
Oct 9, 2026
AI Companies Need More Than a Product Demo to Win Enterprise Trust
Cybersecurity briefing
/
Oct 8, 2026
As AI Makes Impersonation More Convincing, Security Training Becomes More Critical
Cybersecurity briefing
/
Oct 7, 2026