Governed Autonomy: Where the Human Approval Gate Belongs in an Agentic SOC
The loudest claim in the agentic SOC market right now is a percentage. It measures how much of Tier-1 the machine handles without a person. Ninety-five percent. One hundred percent. Fewer than two percent escalated. The number is doing a lot of work, because it quietly reframes the human as the thing to engineer out.
There is real pressure behind it. CrowdStrike’s 2026 Global Threat Report put the average eCrime breakout time at 29 minutes in 2025, down from 48 minutes the year before, with the fastest observed breakout at 27 seconds, a pace HawkEye’s threat advisories track week to week. A SOC that waits on a human for every decision will lose that race. But a SOC that lets software isolate a production host on a false positive loses a different, more expensive race, and in a bank or a ministry it also loses the audit.
So the useful question for a regulated environment is not how much the machine does. It is which actions it is permitted to take on its own, which ones stop for a person, what decides the difference, and what the record looks like afterwards. At HawkEye we call that governed autonomy, and this post is about how the gate is built.
Human-in-the-Loop Is a Design Decision, Not a Dial
The phrase gets used as if it describes a slider between “manual” and “autonomous.” It does not. Two caricatures sit at the ends of that slider, and neither works.
- Everything gated: Every action waits for a click. This is legacy SOAR with a person as the final step of the playbook. The agents did the reading, the human still does all the deciding, and nothing about response speed changed.
- Nothing gated: The system acts on its own verdicts. Fast, until the first confident mistake isolates a payments host during settlement, or revokes the sessions of a privileged service account mid-batch.
Real human-in-the-loop design sits between those, and it is organized by what an action does, not by how confident the model is. Confidence tells you how sure the system is. It tells you nothing about how much damage it does if it is wrong.
Action Classes, and Why They Are Gated Differently
The agents in HawkEye’s AI SOC can take five kinds of action against the environment. Each class carries a different blast radius. That means how many users or systems it touches, how hard it is to reverse, and how critical the asset is. That blast radius, not the confidence score, is what decides whether a person has to be in the loop.
- Read and enrich: Query VirusTotal, pull identity logs from Entra ID, correlate against prior alerts, retrieve organizational memory. Reversible, no production effect. Never gated.
- Record: Open a ticket with the full forensic context, post a critical-alert notification to Teams or Slack, attach evidence to the case. Automatic.
- Contain, reversible: Block an IP at the perimeter, quarantine an email, pull a URL from the allow list. Gated by default. Policy can release it automatically for low-criticality assets when confidence is high, because the cost of being wrong is a few minutes of inconvenience and one undo.
- Contain, disruptive: Isolate a host, revoke active sessions, force re-authentication, disable an account. Always gated. These interrupt work, and some of them interrupt revenue.
- Change: Tune a detection rule, modify a policy, adjust a threshold. Gated, with a second reviewer, because a bad change here silently degrades every future verdict.
Most of the volume in a SOC lives in classes 1 and 2. That is where the “95 percent automated” number comes from, and it is a legitimate win. The design question is entirely about classes 3 through 5, and that is where the vendor percentages go quiet.
One Agent Holds the Keys
HawkEye runs five agents. They are the L1 Triage Analyst, Threat Intel Analyst, Investigation Agent, Alert Summarizer, and Responder. Four of them are read-only against the environment. Only the Responder has write access to enforcement systems, and it is the only agent the approval gate ever applies to.
This is separation of duties, borrowed from how a bank’s own controls work. It does three things. A wrong verdict upstream cannot execute anything on its own. It can only propose. The gate has exactly one place to live, instead of being scattered across every agent that might touch a firewall. And when an auditor asks “what can this system do without a person,” the answer is a short list attached to one component, not a search through five.
Writing the Gate Down as Code
A gate that lives in a settings page is a gate nobody can review, version, or test. HawkEye expresses response policy as code, in the style of Open Policy Agent’s Rego, so that the rule deciding whether an action runs unattended is a file a security engineer and an auditor can both read. Below is a simplified, illustrative example.
package soc.response
default decision := “require_approval”
# Enrichment is never gated
decision := “allow” if {
input.action.class == “enrich”
}
# Reversible containment auto-releases on low-criticality assets
decision := “allow” if {
input.action.class == “contain_reversible”
input.asset.criticality == “low”
input.verdict.confidence >= 0.9
}
# Privileged service accounts need two reviewers
decision := “require_dual_approval” if {
input.target.identity_type == “service_account”
input.target.privileged == true
}
The inputs are what the agents have assembled by the time the Responder proposes an action. They include the action class, the asset’s criticality tag, the verdict confidence, whether the target is a human or a service account, and whether it is privileged. The output is one of allow, require approval, require dual approval, or deny.
Writing it this way has a side effect that matters more than it looks. The policy file is itself audit evidence. When an examiner asks what the system is allowed to do alone, you hand them the policy and its change history, not a screenshot of a configuration page that may have looked different last quarter.
Approval Fatigue Is the Failure Mode Nobody Budgets For
If every containment stops for a click, the people clicking will start approving without reading. That is not a training problem. It is what any human does when a queue of near-identical approvals arrives faster than they can read the evidence. And the people doing the approving are the scarce resource. ISC2’s 2025 Cybersecurity Workforce Study found 59 percent of organizations reporting a critical or significant skills gap, up from 44 percent the year before. A gate that burns senior analyst attention on low-stakes approvals defeats its own purpose.
Four design choices keep the gate meaningful.
- Confidence-weighted routing: High confidence plus low blast radius releases automatically under policy. The gate is reserved for decisions that need judgment.
- Batching by case: Five actions against the same incident arrive as one approval with one narrative, not five separate prompts.
- Time-boxing with escalation: An approval that sits unanswered past a threshold escalates to the next person, rather than silently holding containment open.
- A readable summary: The Alert Summarizer exists so the approver reads one coherent account of what happened and why the action is proposed, instead of reconstructing it from raw findings. A gate is only as good as what the person at it can see.
What the Approval Record Has to Capture
The gate produces a record. For it to be worth anything later, the record has to answer, on its own, every question an incident review or an examiner will ask.
- The action requested, with its class and target
- Which agent proposed it, and the verdict and reasoning trace it was based on
- The policy rule that routed it to a human, by rule name and version
- Who approved, rejected, or modified it, and when
- What executed, and whether the result matched what was proposed
For a bank operating under Saudi Arabia’s SAMA Cyber Security Framework, or an entity in scope of the UAE’s Information Assurance Regulation, this is the difference between a control that can be shown to operate and one that can only be asserted. Both frameworks expect evidence that controls work, not a description of them. The approval log, paired with the reasoning trace behind each verdict, is that evidence. We cover what the trace itself has to contain in the companion post, “Anatomy of a Reasoning Trace” (link once live).
Where This Leaves “Autonomous”
Measure autonomy in actions safely delegated, not in the percentage of alerts closed. By that measure, a SOC where the agents enrich everything, record everything, contain the reversible stuff on their own, and stop for a person only when the blast radius warrants it is a highly autonomous SOC. It is also one a regulator can sign off on, because every line of that sentence is written down as policy and every exception to it is logged.
That is the version of autonomous worth building toward. The other version is fast until it is not.
Frequently Asked Questions about Human-in-the-Loop in an Agentic SOC
What is governed autonomy in an agentic SOC?
Governed autonomy means an agentic SOC‘s AI agents act on their own for low-risk actions such as enrichment, ticketing, and reversible containment, while disruptive actions such as isolating a host or disabling an account stop for human approval. Which actions fall on which side is defined in a written, versioned policy rather than decided case by case.
Does a human approval gate slow down incident response?
Not when it is scoped by action class. Enrichment, correlation, and case documentation run at machine speed with no gate. Only disruptive or high-blast-radius actions wait, and by the time they do, the agents have assembled the full evidence and a readable summary, so the approval itself takes seconds rather than the minutes a manual investigation would.
Which SOC actions should always require human approval?
Actions that interrupt users or revenue and are hard to reverse. That means isolating a host, revoking sessions, forcing re-authentication, disabling an account, and any change to detection rules or policy. Actions against privileged or service accounts warrant a second reviewer, because the blast radius is largest and the identity cannot explain itself.
How is this different from an approval step in a SOAR playbook?
A SOAR approval step is a fixed point in a fixed playbook. In an agentic SOC the agents reason over each alert’s specific context and propose an action based on that reasoning. The policy then decides, per action and per asset, whether a person needs to be involved. The gate adapts to the case instead of the case being forced through the playbook.