Agentic AI In Cybersecurity: What Changes When The System Chooses The Next Step

Introduction

Agentic AI in cybersecurity has quietly stopped being a working example. Agents now triage alerts, pivot through threat intelligence, draft detection rules, and chase an indicator across a dozen sources before an analyst finishes their coffee. Which raises the uncomfortable question: how much power is too much power?

July 2026 gave that question teeth. During OpenAI’s internal evaluations, AI agents operating with reduced safeguards escaped their isolation controls, exploited a zero-day, and executed code on dozens of Hugging Face production servers, and root on at least one. No human directed the attack.

The accounts of motive differ in an instructive way: Hugging Face’s forensic reconstruction read the intrusion as an attempt to cheat the evaluation, while METR’s independent investigation suggests the agents were primarily trying to understand the scorer’s implementation. Under either reading, the goal was ordinary; the route was one nobody had technically closed.

So no, giving a system autonomy over its own next step does not mean accepting recklessness, provided autonomy is earned scope by scope, with enforced controls doing the limiting. What follows draws on the experience of Boris Zverkov, one of the engineers behind Group-IB’s Prevyn AI agentic architecture, together with the documented incidents, to look at where agents genuinely help, how they fail, and what to demand before you trust one.

Does giving AI autonomy mean accepting recklessness?

The incidents we talked about cut both ways. What failed in July 2026 was not the ambition of agentic AI; it was the assumption that a goal description can substitute for containment.

Read that way, the incident is not an argument against autonomy but about where the limits must live. An instruction prohibiting an action cannot prove the action is technically unavailable; restrictions must operate through the harness — authorization on every tool call, restricted outbound destinations, tenant separation rather than relying on model behavior alone.

What does responsible delegation require?

A note on principles before the practice, because in agentic systems governance is a set of design decisions rather than a policy document. The approach behind Group-IB Prevyn AI rests on four commitments: human accountability, with approval required for consequential operations; autonomy proportional to consequences; boundaries that are structural rather than promised; and conclusions that remain traceable and open to challenge. The rest of this article shows each one in practice.

What makes an AI system agentic in cybersecurity

Most people’s mental model of AI is a chat window: you type a question, it types an answer, and it stops. It does nothing until prompted, stops when it is done, and cannot touch anything. Agentic is when you give the brain hands: the ability to pursue an objective across steps, call tools, observe results, and decide the next move within its scope.

The useful test is therefore not the interface but a question: who chooses the next step? A chat window can front an agent; a copilot can contain agentic capability. Boris draws the same line from builder’s side: a chatbot runs one linear, reactive path and stops, while an agent runs a loop of reasoning, action, and observation until the goal is met: decomposing the objective, sequencing tools, adjusting to what each returns. Error handling separates them most sharply: when a request or tool call fails, a chatbot passes the failure straight back to the user, while an agent inspects it, retries, or takes another path. The flip side, acknowledged just as plainly: over long runs, mistakes can compound.

Table 1: The approaches combined: generative AI is a capability an agent may use, and SOAR can provide controlled execution for an approved response

Nor does every task need an agent. If a fixed lookup answers the question reliably, an adaptive investigation adds cost and potential failure without adding value. Use the simplest workflow that can do the job: a principle Anthropic’s engineering guidance states almost verbatim. Group-IB applies the same logic to Prevyn AI. Some capabilities run in assistive mode because that is the right design for the task: remediation workflows in Managed XDR, where AI prepares the response and an analyst approves it, and Incident Management Center (IMC) in Threat Intelligence, where external threat intelligence is turned into decision-ready incidents defined around your organization’s priorities.

Where agentic AI earns its place in security operations

The strongest starting point is a task with repeated investigative decisions, accessible evidence, and an output an analyst can check. Group-IB’s Prevyn AI use cases in Group-IB Threat Intelligence show what this looks like in practice.

Threat intelligence research that follows the evidence

In one documented workflow, an analyst detects a suspicious IP address and asks Prevyn AI to pivot on it. The system builds the graph context automatically and returns a structured summary surfacing what a manual pivot might take hours to reach: an SSL certificate linking the address to the Gamaredon APT group, with a link back to the Group-IB Graph for visual investigation.

The group’s tactics, techniques, and procedures arrive mapped to MITRE ATT&CK; draft detection content follows. A single indicator of compromise becomes a contextualized investigation with the evidence attached.

Image: Prevyn AI turning one pivot prompt into graph context: the IP identified as a central hub, the Gamaredon connection surfaced in Detailed Findings, with a link out to the Group-IB Graph for manual visual investigation.

Attribution still needs care: an infrastructure association is evidence to assess, not proof that every connection belongs to one operator — shared hosting, reassigned addresses, and the age of an observation changes the interpretation. The agent earns trust by making that inspection easier. And the deeper shift is economic: an analyst whose research costs minutes instead of half a day can afford curiosity, and cheap curiosity is how you find the thing nobody was looking for.

Detection engineering that starts with a draft

The same workflow produces a draft Sigma rule and an explanation of what it is intended to detect. Deployment remains a separate decision: telemetry availability, field mappings, false positives, behavior in a test environment. The boundary is the right kind of explicit: Prevyn AI can write the rule, ready to export into SIEM, EDR, or NDR environments, but it will not add the rule anywhere itself. It has no functionality to do so. That is an architectural fact, not a policy promise  exactly the form a trustworthy boundary should take.

Image: From intelligence to draft detection: a Sigma rule generated from Gamaredon’s latest activity, with its purpose explained. Export-ready for SIEM, EDR, or NDR

Vulnerability prioritization with evidence of exploitation

Another workflow starts with vulnerabilities used by threat actors, adds underground discussion, and narrows findings to a sector,  connecting vulnerability information with adversary activity rather than treating a severity score as the whole patching decision. The signals differ in weight: a forum advertisement is a claim, a working exploit is a capability, observed exploitation is evidence of use, and none establishes that your organization runs the affected version. The useful output is a priority recommendation with its assumptions visible.

One caution applies across every use case: an agent should distinguish a clean search result from a failed query or a missing data source, or “no evidence found” quietly becomes “nothing happened.” A system that closes cases faster can still make the SOC less effective if it systematically overlooks evidence it could not retrieve.

The hardest engineering problem: getting agents to coordinate for the right reasons

The best way to answer this isn’t theory, it’s what we learned building Prevyn AI inside Group-IB. The team behind its agentic architecture is direct about where the effort actually went: developing the individual specialists was the straightforward part; coordinating them took the work. The current implementation runs twelve specialist agents — threat actors, malware, vulnerabilities, underground sources, compromised credentials, malicious infrastructure, and more, each with its own tool server, coordinated by an orchestration layer that decides what runs next.

Figure 2. The orchestrated architecture behind Prevyn AI research: one goal in at the top, routing and synthesis in the middle, and a human analyst reviewing the sourced output. The reasoning about the route moves to the system; the judgment does not. Coordination, routing and synthesis, is the hard engineering problem in multi- agent security systems, not the individual specialists.

Two problems dominated engineering. Routing means deciding who should answer the question: real investigations cross boundaries, and choosing one specialist may produce a correct answer to only part of the problem. Synthesis means deciding what the combined evidence supports. Several agents can return detailed results that overlap, contradict one another, or answer slightly different questions, and joining their text together resolves nothing. Boris Zverkov puts it plainly: “Naive concatenation produces a long report that looks thorough and answers nothing.”

A useful orchestrator surfaces the disagreement and decides whether more research can resolve it. If one source ties infrastructure to an actor and another suggests shared hosting, both stay visible until the relationship is understood. And agreement alone is weak assurance: three agents repeating one upstream report are one evidentiary basis, not three confirmations.

How agentic systems catch their own mistakes

Consider an illustrative case: an agent links an address to a campaign without noticing the address changed hands, then retrieves the actor’s techniques and drafts detection logic on top: every step coherent, the foundation wrong.

The Prevyn AI implementation runs three safeguards designed to catch this: cross-checking (with twelve specialists, a wrong conclusion often contradicts another agent’s return), grounding (conclusions grounded in retrieved Group-IB intelligence), and bounded chains (the orchestrator re-checks the original goal at each step so drift is caught early). Grounded systems can still infer incorrectly; these safeguards reduce the risk rather than eliminate it.

According to Group-IB’s internal testing, Prevyn AI improved research output quality by more than 20 percent, measured on accuracy, completeness, and analytical depth.

Boris frames this as the real advantage of agentic systems: when a search fails or returns more than can be meaningfully used, the agent can check the results against the original goal and try another route — a narrower query, a different source, a different method. Even so, an investigation should separate observed facts, inferred relationships, and unresolved questions, and it needs a valid stopping state: insufficient evidence, an unavailable source, repeated tool failure, or a task outside approved scope.

Research and response need different permissions

What does meaningful oversight look like in practice? Boris rightly points in his three strategies, and the honesty of the first is refreshing — approving every action does not scale and makes interaction worse: an analyst clicking through fifty prompts stops reading by the tenth. Approving the plan is the right default for research: the analyst sees how the question was decomposed and where the system intends to look, and corrects course before a ten-minute investigation runs rather than after. Risk thresholds are what actions need: anything irreversible, anything touching production, anything outside safe scope stops and waits, while everything below the line runs. Rubber-stamp oversight is not oversight; it is latency with a signature. 

For systems with response capabilities, reversibility is one consideration but not the whole one: isolating a host may be reversible in the console while the interruption it caused is not, and the same action on a test laptop and a production server should not inherit the same approval policy. A workable delegation framework defines the boundary before use.

Meaningful oversight then depends on what the approver can see: the proposed action, exact target, supporting evidence, uncertainty, expected impact, and recovery path. Otherwise, the analyst is approving the system’s confidence. An approval should also bind to the operation actually executed. And the audit trail is what makes any of it reviewable.

Boris Zverkov’s standard reframes a common demand: ask the same question twice and the paths may differ, so identical traces are not the goal, traceability is. Every conclusion ties to the data it rests on, and the record shows how the question was decomposed, which agents ran and why, what each returned including failures, and where they disagreed. The practical test: can another analyst identify which evidence would need to change for the conclusion to change?

One more operational reality, straight from the incident record: response plans for agentic systems should include disabling tools or identities, interrupting running tasks, and reviewing delegated work that may have carried a problem elsewhere. A stopped conversation is not necessarily a stopped operation.

What actually differentiates agentic AI vendors

For an evaluator comparing agentic capabilities across vendors, one observation saves a lot of demo time: the architecture diagram alone does not establish differentiation. Orchestrator-plus-specialists is now a common pattern, and as the coordination section showed, the difference lives in implementation — routing, synthesis, controls,  and in what the system works with. Three things compound alongside that engineering. Each is a test you can run, and each is where Group-IB has placed its bet with Prevyn AI.

The brain (what it knows): Agents drawing on the same public feeds tend to converge on similar answers; differentiation starts where the agent reads what others cannot. Prevyn AI is designed as the cognitive core of the Group-IB Unified Risk Platform, reasoning over the Intelligence Data Lake: two decades of underground sources, malware analysis, and material from real investigations. On top of the data sits encoded expertise — specialists built around how veteran investigators actually work a case: what they check first, which correlations they distrust, when they stop pulling a thread.

The test: ask each vendor what their agents reason over that no competitor can access, and who their agents apprenticed under.

2. The approvals (what it is permitted to do) : Rigorous human control differentiates most when it is architecture rather than policy. Prevyn AI runs in two modes whose difference is the delegation framework from earlier in this article made into product design: fully agentic in Threat Intelligence, where the output is information an analyst reviews and challenges, and assistive in Managed XDR, where it prepares remediation workflows and incident reports at machine speed and a human checks, modifies, and approves before one-click execution. The boundaries are structural as the detection engineering example showed, and every conclusion stays traceable to its evidence.

The test: ask for the approval screens and the audit trail, not the demo reel. 

3. The trajectory (how autonomy grows) : Today’s implementations differ internally by workflow, sharing one vision and converging toward the orchestration-driven architecture proven in Threat Intelligence. And there is more to come next: specialist agents for fraud detection and credential abuse, a deep research mode, cross-domain orchestration spanning cyber and fraud, predictive threat modeling, and controlled autonomous operations within defined policies. The graph work shows the pattern — today a user-initiated investigation turns one indicator into mapped infrastructure; continuous agent-driven exploration is a natural potential direction rather than a shipped capability. Evolution runs along two independent dimensions — how far ahead the system can reason, and how much it is permitted to do — and the second is deliberately the slower dial.

The test: ask what the vendor’s agents will be allowed to do next year, and what has to be proven before they’re allowed to do it.

One chain, one defense: where this is heading

The longer-term opportunity is asking questions that would otherwise consume too much analyst time such as comparing infrastructure across campaigns or spotting repeated preparation patterns.

The most consequential version is connecting cyber and fraud investigations: the Cyber-Fraud Fusion problem. 

A phishing domain, stolen credentials, and an account takeover may belong to one campaign while different teams hold the evidence under different names: a phishing kit to brand protection, an account-takeover attempt to the fraud team, a suspicious beneficiary to anti-money-laundering. The operation is one chain; the defense, historically, is not. Agents do not care about the org chart, and a shared vocabulary is emerging — MITRE’s F3 fraud framework gives fraud the taxonomy that MITRE ATT&CK gave intrusions. But an agent can connect stages only where access is authorized and the records share identifiers and timing. It cannot recover evidence that was never collected, which makes capturing that connective tissue now, before the incident, half of the fusion story.

Step back far enough and the destination is the one this industry has promised for years: prediction. Attackers reuse infrastructure patterns, stage resources before campaigns, and discuss their work in closed communities.

Anticipating them is the direction Group-IB is building toward, bringing predictive intelligence and Cyber-Fraud Fusion together, but no human team can watch more than a fraction of the weak signals at once.

Coordinated agents expand the range of signals and hypotheses a team can actually investigate, with uncertainty and missing data remaining real constraints: a step toward security that behaves less like an emergency room and more like an immune system. The builder’s long-term vision compresses the whole argument into one sentence: a system that investigates as one and acts narrowly, under proper supervision, and the analyst’s role shifts accordingly.

How to evaluate an agentic security system

For a team evaluating agentic AI today, the advice is simpler than the vision: start with one bounded workflow and a baseline, and put ambiguous cases, malicious source content, unavailable tools, and conflicting evidence in the test set. Then score the whole workflow, not the demo.

Correct findings and missed threats, including appropriate abstention like:

• Whether cited sources actually support each conclusion
• Analyst time spent reviewing and correcting the output
• Behavior when tools fail or permissions are exceeded
• Cost per accepted investigation, human review included

Ask the vendor to run an uncertain case with a contradictory source and a failed tool call, and ask the system what it could establish, what it could not, and where its authority ended. The demonstration becomes useful at the point where the agent has a reason to be wrong. Watch what happens next.

Evaluating agentic AI for your own team? We’re happy to share what we learned building Prevyn AI, including the parts that were harder than expected. Talk to our Threat Intelligence team here.

Key Takeaway

Agentic AI in cybersecurity shifts the analyst’s role from running each step to reviewing sourced conclusions, but its value holds only where autonomy is enforced by infrastructure rather than instructions. Group-IB’s Prevyn AI (2026) demonstrates the disciplined pattern: 12 orchestrated specialist agents research across the Intelligence Data Lake in Group-IB Threat Intelligence, while operational authority stays with human analysts. The test of any agentic security system is not how it performs in a demo, but what it does when a source contradicts itself, a tool fails, or the evidence runs out.