More AI Will Not Fix a Poorly Designed SOC

REDSAND | THE CTO FIELD NOTES

By Tim Shelton | Founder & CTO, HAWK Network Defense

AI is rapidly becoming the answer to nearly every security operations problem.

Too many alerts? Add AI.

Investigations take too long? Add AI.

Analysts are overwhelmed? Add AI.

Containment is slow? Add more AI.

But AI cannot repair an operating model that was never designed to produce fast, reliable security decisions.

If alerts arrive without context, workflows cross disconnected tools, escalation paths remain unclear, and every meaningful response requires manual approval, adding AI does not eliminate the underlying dysfunction.

It automates pieces of it.

In some cases, it accelerates it.

A poorly designed SOC with more AI may generate summaries faster, prioritize queues more quickly, and recommend actions sooner.

But if the surrounding system cannot turn those outputs into trusted and authorized action, the organization still has the same bottleneck—now operating at greater speed, scale, and cost.

The problem is not a lack of intelligence.

It is the design of the system in which that intelligence is expected to operate.

Why AI Cannot Fix Fragmented Security Operations

Most security operations centers did not become fragmented through one deliberate architectural decision.

The fragmentation accumulated over time.

A new security tool was purchased to address a specific threat.

Another platform was added to improve endpoint visibility.

Identity data remained somewhere else.

Asset criticality was maintained in a configuration management database that was not always current.

Threat intelligence arrived through separate feeds.

Incident response depended on tickets, messaging platforms, email, phone calls, and individual knowledge.

Each system may provide value independently.

The operational problem appears when analysts must manually assemble those pieces during an active incident.

An AI assistant may summarize an alert, but it still needs accurate context.

It may recommend containment, but the organization must determine whether the action is permitted.

It may identify suspicious behavior, but someone must understand what the affected asset supports and what disrupting it could mean for the business.

If the data is fragmented, the AI receives fragmented context.

If authority is unclear, the AI produces recommendations that wait for approval.

If workflows are inconsistent, automation encounters exceptions the operating model never resolved.

AI does not remove those dependencies. It inherits them.

Faster Security Analysis Is Not the Same as Faster Protection

The security industry often treats analytical speed as though it were equivalent to operational speed.

It is not.

AI may reduce the time required to review an alert from several minutes to several seconds.

That is useful.

But it does not necessarily reduce the time required to contain the threat.

The full decision and response path still matters:

SIGNAL → CONTEXT → DETERMINATION → AUTHORITY → ACTION → VERIFICATION

AI may accelerate signal analysis and determination.

But the incident can still stall while the system searches for context, waits for authority, transfers the case to another team, or depends on a person to execute the response.

Consider an AI system that determines within seconds that a credential is likely compromised.

What happens next?

Does it know which systems the identity can access?

Can it distinguish an ordinary employee account from an emergency production account?

Is it authorized to disable the credential?

Does the action require confirmation from identity, legal, operations, or management?

Can it revoke active sessions across the connected platforms where that response is required?

Will the organization know whether the response succeeded?

If those questions are not answered in advance, faster analysis simply delivers the incident to the same operational bottleneck sooner.

Faster analysis creates value when the organization can translate it into faster, defensible protection.

AI Can Scale Bad Security Processes

Automation is powerful because it makes repeatable processes faster and more consistent.

That is also what makes automating a poor process dangerous.

If a SOC routinely creates multiple tickets for the same incident, AI may create them faster.

If asset data is unreliable, AI may confidently prioritize the wrong system.

If escalation criteria are inconsistent, AI may reproduce those inconsistencies across thousands of decisions.

If analysts rely on tribal knowledge to interpret alerts, an AI model may provide an answer without capturing the institutional reasoning that makes the answer valid.

If every response requires a manual handoff, AI may increase the number of recommendations waiting in the next team's queue.

The organization can appear more automated while becoming no more effective.

This is how AI can turn operational friction into automated operational friction.

The process moves faster.

The result does not improve.

Why More AI Can Create More Security Operations Work

The assumption behind many AI investments is that additional intelligence will reduce analyst workload.

That depends on how the system is designed.

An AI tool that adds another score, summary, recommendation, or interface may give analysts one more output to validate.

If security teams do not trust the model's context or reasoning, they may repeat the investigation manually.

Now the analyst is reviewing both the incident and the AI's interpretation of the incident.

AI can also increase the volume of observable activity.

Systems that identify more anomalies, generate more hypotheses, or find more possible attack paths can create more investigative demand than the SOC can absorb.

That does not necessarily mean the technology failed.

It means discovery capacity grew faster than decision and response capacity.

The result may be:

• More signals competing for attention

• More AI-generated findings requiring validation

• More recommendations waiting for approval

• More integrations that must be maintained

• More model outputs that must be governed

• More infrastructure and token consumption

• More uncertainty about which system produced the final decision

The SOC becomes technically more capable but operationally more congested.

That is not transformation.

It is additional technology layered over an unresolved operating-model problem.

Redesign the SOC Around Decisions, Not Alert Queues

The traditional SOC was largely designed around alerts.

Signals entered a queue.

Analysts reviewed them, gathered context, opened cases, escalated findings, and coordinated response.

AI creates an opportunity to change that model—but only if leaders redesign the SOC around decisions rather than simply adding intelligence to the existing queue.

A decision-centered SOC should determine:

• What evidence is required to reach a reliable conclusion

• Which context must be assembled automatically

• Which decisions are repeatable and policy-defined

• Which actions may be executed automatically

• Which assets and scenarios require human judgment

• Who owns authority when escalation is necessary

• How quickly every handoff must occur

• How decisions and actions will be preserved for review

• How the system verifies that containment succeeded

These are operating-model questions.

AI may help execute the resulting design.

It cannot substitute for making those decisions.

Without that foundation, organizations risk purchasing AI to compensate for structural problems they have not been willing to resolve.

The SOC should be designed around defensible decisions and verified outcomes—not simply the volume of alerts it processes.

Fix the Security Context Before Adding More Intelligence

AI decisions are only as reliable as the context supporting them.

A SOC cannot expect an AI system to understand operational risk when asset ownership is unknown, identity relationships are incomplete, host telemetry is disconnected, and business criticality is outdated.

The first priority should be ensuring that relevant information can be assembled into one defensible incident view.

That includes:

• The affected identity

• The endpoint or host

• Recent activity surrounding the event

• Related signals across the environment

• Asset criticality and business function

• Known vulnerabilities and exposures

• Privileges and accessible systems

• Threat intelligence relevant to the behavior

• Available containment actions

• The evidence supporting the final determination

AI can accelerate reasoning across this information.

It should not be expected to invent information the organization never maintained.

Trusted context is not a luxury to be added after automation.

It is part of the foundation that makes reliable automation possible.

Define Security Decision Authority Before Automating Action

A recommendation is not containment.

If AI can determine that an incident requires action but cannot execute the response, the decision still enters a human queue.

That may be appropriate for ambiguous or high-consequence situations.

It should not automatically be the default for every routine, repeatable incident.

Organizations must establish bounded authority before expecting AI to reduce response time.

The system should know:

• Which actions it may take independently

• The confidence and evidence thresholds required

• Which assets are excluded from automatic action

• Which responses are reversible

• When human approval is mandatory

• When the system must stop and escalate

• How emergency authority can be revoked

• How every decision and action will be audited

Too little authority leaves AI trapped at the recommendation layer.

Too much authority creates unacceptable operational risk.

The objective is not unlimited autonomy.

It is carefully designed authority that allows routine, well-supported decisions to move at machine speed while preserving human control over uncertainty and consequence.

That authority should be technically enforced, monitored, and capable of being reduced or revoked when conditions change.

Measure Security Outcomes Instead of AI Activity

A SOC should not measure AI success by the number of alerts summarized, prompts processed, investigations assisted, or recommendations generated.

Those are activity measures.

The operational questions are more important:

• Did the system reduce time to decision?

• Did it reduce time to verified containment?

• Did it eliminate unnecessary manual enrichment?

• Did it reduce avoidable handoffs?

• Did fewer routine incidents require analyst attention?

• Did decisions become more consistent and reviewable?

• Did the organization preserve evidence and accountability?

• Did containment occur before business impact?

If those outcomes do not improve, more AI may be increasing technological sophistication without improving security operations.

A new AI capability should remove a measurable constraint from the decision path.

If leaders cannot identify which constraint it removes, they may be adding another layer rather than solving the problem.

Automation value should be measured by the operational friction removed and the security outcomes achieved.

Redesign the SOC Before Scaling AI

The right question is not:

Where can we add AI to the SOC?

It is:

What prevents this SOC from making and executing the right decision quickly?

The answer may be incomplete context.

It may be disconnected tools.

It may be unclear ownership.

It may be excessive approvals.

It may be an inability to execute containment from the investigation workflow.

It may be a lack of trust in the evidence.

Those constraints should be addressed as a connected system.

Only then can AI create its full operational value.

AI should help the SOC correlate evidence, reduce repetitive work, make defensible determinations, execute approved actions, and preserve an accountable record of what occurred.

It should not become an expensive layer placed over an operating model that still depends on analysts manually holding the system together.

What Security Leaders Should Evaluate Before Investing in More SOC AI

Before expanding AI investment, I would evaluate whether the existing SOC can consistently answer five questions.

1. Can We Establish Trusted Context?

Can analysts and automated systems reliably connect identities, assets, signals, exposures, and business criticality without repeatedly reconstructing the incident from disconnected sources?

2. Can We Reach a Defensible Decision?

Does the operating model establish what evidence is required, which conclusions are sufficiently supported, and when uncertainty requires further investigation or escalation?

3. Is Decision Authority Clearly Defined?

Does the organization know which actions can occur automatically, which require human judgment, and which must be prohibited?

Are those boundaries technically enforced?

4. Can We Execute and Verify Containment?

Can the organization move from determination to authorized action without unnecessary handoffs?

And can it verify that the intended security condition was achieved?

5. Can We Demonstrate Operational Improvement?

Will the proposed investment reduce decision latency, unnecessary analyst work, or time to containment?

Can those improvements be measured?

These questions help distinguish AI that contributes to a better security operating model from AI that simply adds more processing capacity.

REDSAND | The CTO Field Notes

AI does not transform a SOC simply because it has been added to the technology stack.

Transformation occurs when the operating model changes.

A well-designed SOC uses AI to reduce the distance between signal and trusted action.

A poorly designed SOC uses AI to move more information into the same fragmented workflows, unclear authority structures, and human bottlenecks.

The difference is not model capability.

It is system design.

Before security leaders purchase more AI, they should determine whether their SOC can reliably assemble context, make decisions, exercise authority, execute containment, and prove why each action occurred.

If it cannot, more AI will not fix the problem.

It may only allow the problem to operate faster.

Redesign the decision system before you scale the intelligence.