Agentic AI in the SOC is moving from hype to governed execution

At a glance

What this is: This is a Black Hat Europe recap arguing that agentic AI is becoming operational in SOC workflows, with Virgin Atlantic presented as evidence that automation can remove Tier-1 toil and accelerate response.

Why it matters: It matters because SOC automation now intersects directly with identity, access, and execution control, which means IAM, PAM, and NHI governance must keep pace with machine-driven decisioning.

By the numbers:

• Torq said its EMEA quarterly target hit 185% and regional customer growth rose 284%.
• Virgin Atlantic said one junior analyst turned roughly 40 hours of weekly manual work into fully automated workflows in less than two weeks.
• Virgin Atlantic said it saw a rise in conceptual attacks and supply chain incidents over 18 months that legacy tooling could not keep up with.

👉 Read torq’s Black Hat Europe recap on agentic AI in the SOC

Context

Agentic AI in the SOC refers to software that can plan, reason, and execute actions across security tools with limited human prompting. The governance problem is not just speed, but whether that execution layer is controlled tightly enough to avoid accidental privilege expansion, unsafe remediation, or opaque automation across identity and cloud systems. In this case, the article is about SOC operations, but the identity angle is real because every automated response depends on NHI credentials, API permissions, and policy boundaries.

Torq uses Virgin Atlantic as the proof point for a broader operational shift: analysts are being asked to move from repetitive triage to supervised automation, and leaders want evidence that the model works under real incident pressure. That is a typical enterprise challenge, not an unusual one, which makes the underlying question broadly relevant for security programmes designing governed automation across SIEM, IAM, EDR, CSPM, and SaaS tooling.

Key questions

Q: How should security teams implement agentic AI in SOC workflows safely?

A: Start with narrow, high-confidence use cases such as alert triage and evidence gathering, then require explicit policy gates before any remediation action. Use dedicated machine identities, least privilege, and full audit logging so the AI cannot exceed its assigned scope. The safest deployments treat autonomy as a controlled exception, not the default operating mode.

Q: Why do agentic security tools change identity governance requirements?

A: Because the risk is no longer only whether the tool detects accurately. The system can now choose actions, consume telemetry, and perform remediation, which creates a lifecycle and privilege problem. Identity teams need to govern who can approve those actions, what data can justify them, and how the system is removed when its role changes.

Q: What do security teams get wrong about hyperautomation in the SOC?

A: Teams often focus on throughput and ignore authority. Hyperautomation is not just about handling more alerts faster, it is about deciding which actions a machine may take and under what evidence conditions. If those boundaries are vague, automation can amplify errors, create over-privileged workflows, and obscure accountability when the system acts incorrectly.

Q: What should teams do before letting agentic AI touch production response workflows?

A: Start with low-risk use cases, then prove that every automated action can be observed, approved where needed, and reversed if the outcome is wrong. The first production rollout should prioritise containment, auditability, and identity checks, not maximum autonomy. That approach protects both the SOC and the business.

Technical breakdown

How agentic SOC workflows execute across multiple tools

Agentic SOC systems combine an LLM-driven planner with tool connectors, case state, and policy checks. The agent does not just summarise alerts. It can enrich evidence, create or update a case, query identity and cloud systems, and trigger approved response steps. The security issue is that this execution path depends on delegated credentials and scoped permissions, so the real control boundary sits in the orchestration layer, not the model itself. If that boundary is loose, the agent becomes a privilege amplifier rather than a productivity layer.

Practical implication: define hard policy gates around what the agent can query, change, or remediate before you allow it to touch production systems.

Why identity context matters in automated investigation

The article’s strongest technical point is that the demo spans SIEM, EDR, IAM, CSPM, and SaaS. That matters because investigation quality improves when identity signals are joined with endpoint and cloud telemetry. In practice, an alert often becomes actionable only after the system checks who or what executed the action, what privileges were present, and whether the identity behind the event is human, service, or machine. That makes NHI governance central to trustworthy automation, because the agent itself runs as an identity and consumes other identities as inputs.

Practical implication: tie automated investigation steps to identity enrichment so response decisions reflect privilege, ownership, and trust context.

What governed automation means in a high-volume SOC

Governed automation is not the same as autonomous decision-making. It means predefined constraints, audit trails, and escalation paths remain in place even when machine speed compresses the workflow. The article stresses safe execution with clear policy constraints, which is the right design principle for SOCs that cannot afford uncontrolled remediation. The architecture should support human override, step-level logging, and bounded actions for each use case, especially where account disablement, token revocation, or case closure could create business disruption if misapplied.

Practical implication: require use-case-specific approval thresholds and rollback paths for every automated response that changes identity or access state.

NHI Mgmt Group analysis

Agentic AI in the SOC is becoming an NHI governance problem, not just a SOC efficiency story. The article shows AI systems planning and executing actions across identity and security tooling, which means they operate as non-human identities with delegated authority. That shifts the control question from model accuracy to privilege design, policy enforcement, and auditability. The decisive issue for practitioners is whether the automation layer can be governed like any other high-trust identity path.

Bounded autonomy is the only defensible operating model for security automation. The Torq session emphasises policy constraints and safe execution, which is the right direction for agentic SOC use cases. Once an automated system can enrich, decide, and act, the governance baseline needs to separate recommendation from execution. Without that separation, automation becomes difficult to explain after the fact and harder to contain during failure. Practitioners should treat this as a control design issue, not a tooling preference.

Identity context is what prevents agentic systems from becoming blind responders. When a SOC agent can see IAM, endpoint, cloud, and SaaS signals together, it can make better decisions about whether an event is user-driven, service-driven, or machine-driven. That intersection is exactly where NHIMG’s perspective matters: the identity of the acting system and the identities it touches determine whether response is safe. Practitioners should demand identity-aware orchestration before expanding agentic workflows.

Agentic SOC programmes will expose automation debt faster than legacy SOAR ever did. The article positions low-code, fast deployment, and analyst productivity as the big wins, but those gains also reveal where old workflows were too rigid or too manual. Programmes that rely on brittle playbooks will struggle to scale this model. The practical conclusion is that teams need clear ownership, tested policy boundaries, and an operating model for continuous adjustment as the automation surface grows.

What this signals

Agentic SOC adoption will force security teams to treat automation platforms as governed identities, not just workflow engines. That means access scoping, approval design, and audit fidelity become deployment blockers if they are not solved early. The signal for practitioners is clear: supervised autonomy is moving from experiment to operating model, and the identity layer underneath it must be engineered deliberately.

Automation accountability debt: the more systems can plan and act at machine speed, the more important it becomes to prove who approved what, which identity executed it, and whether the action stayed inside policy. Teams should align their automation design to explicit control ownership and use NIST Cybersecurity Framework 2.0 as the programme-level structure for govern, protect, detect, respond, and recover.

As SOC teams add AI orchestration across NIST SP 800-53 Rev 5 Security and Privacy Controls domains, they should expect more scrutiny on machine credentials, privilege boundaries, and response traceability. The near-term programme priority is not full autonomy, but controlled execution with measurable blast-radius limits.

For practitioners

• Inventory every privileged connector used by SOC automation Map the IAM, SaaS, endpoint, and cloud accounts that the agent can call, then classify each by blast radius, remediation power, and logging coverage. The goal is to know exactly which delegated identities can query, change, or revoke access before the first production workflow goes live.
• Separate recommendation from execution in every workflow Allow the agent to summarise, enrich, and propose next steps, but require explicit policy logic before it can perform identity changes, token revocation, or incident containment. This keeps response auditable and reduces the risk of an overconfident automation path making an irreversible change.
• Bind automation to identity-enriched case data Make IAM, service account, and machine identity signals part of the investigation record so the SOC can see who or what initiated an action and what privileges were present at the time. That context matters most when alerts cross identity, endpoint, and cloud systems.
• Test rollback before you trust remediation speed Run tabletop and live-fire tests on any automated containment step that can disable an account, isolate a device, or revoke a token. If the workflow cannot be reversed cleanly, the response design is not ready for high-confidence production use.

Key takeaways

• Agentic AI in the SOC is really an identity governance problem because the automation layer executes through delegated access across identity, endpoint, cloud, and SaaS systems.
• The practical value of the approach is tied to controls such as policy constraints, audit trails, and rollback paths, not to AI-driven speed alone.
• Security teams should treat SOC automation as supervised execution and prove that every privileged connector, response step, and identity change is bounded before production rollout.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Governed automation: A governed automation is a workflow that executes a task without giving the requester broad standing access. It uses policy checks, structured inputs, and audit records so the organisation can approve outcomes while keeping privilege narrow and traceable.
• Identity-Enriched Investigation: Identity-enriched investigation is the practice of correlating alerts with account, privilege, and ownership data before response decisions are made. It improves accuracy by showing whether an event was driven by a person, service, or machine identity, and whether the action fits expected access patterns.

What's in the full article

Torq's full article covers the operational detail this post intentionally leaves for the source:

• A live-event walkthrough of the HyperSOC workflow across SIEM, EDR, IAM, CSPM, and SaaS tooling, showing how the automation chain is assembled in practice.
• Virgin Atlantic’s implementation story, including how the team introduced the platform mid-incident and what changed in day-to-day analyst work.
• The specific demo behaviours that distinguish alert enrichment, case building, and policy-constrained response in a real SOC setting.
• The vendor’s framing of what analysts, CISOs, and peers were reacting to at Black Hat Europe, including the audience response to the live demonstration.

👉 Torq's full post covers the Virgin Atlantic session, the live HyperSOC demo, and the operating model behind governed automation.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build the control discipline needed for governed automation and agentic AI.