Past the hype, a real shift

Few topics generate as much noise in our industry right now as agentic AI. Every vendor briefing seems to promise an autonomous security operations centre that triages alerts, investigates incidents and remediates threats while the analysts sleep. Having spent the last period designing and testing agentic workflows for security teams, including within a major banking group and a critical infrastructure operator, my view is more measured. Agentic AI is genuinely useful in security operations. It is also easy to deploy badly, and the failure modes are different from those of the tools we are used to.

By "agentic" I mean systems built on large language models that can plan multi-step tasks, call tools such as a SIEM query interface, an EDR console or a ticketing system, observe the results and decide what to do next, rather than simply answering a single question. That ability to act is what makes them valuable, and it is exactly what makes them risky.

Where it works: the tedious middle of the workflow

The highest value I have seen comes not from replacing analysts but from removing the repetitive work that sits between an alert firing and a human making a judgement. In a typical SOC, a large share of analyst time goes on gathering context: who owns this host, what else did this user do today, has this hash been seen before, is this IP associated with known infrastructure, what does the related email look like. Agents are well suited to this.

• Alert enrichment and triage. An agent can pull asset, identity, threat intelligence and historical data for an alert, summarise it and propose a disposition with its reasoning. The analyst then reviews a structured case rather than starting from a raw event.

• Investigation scaffolding. For a suspected phishing compromise, an agent can run the standard set of queries across mail, identity and endpoint logs, assemble a timeline and flag gaps. This compresses the early hours of an investigation.

• Translating intent into queries. Analysts who are not fluent in every query language can describe what they need in plain language and have the agent draft the query, which they then review and run.

• Reporting and handover. Drafting incident summaries, shift handovers and executive briefings from the case record is a strong use case, provided a human edits and approves the output.

• Detection engineering support. Agents can help test detection rules against historical data, suggest tuning and document the logic, accelerating work that is often deprioritised.

In each of these, the agent prepares and the human decides. That division is the single most important design principle I recommend.

Where it does not work, yet

The disappointments I have seen tend to share a root cause: giving an agent authority before it has earned trust, or expecting it to compensate for weak foundations.

• Fully autonomous containment. Allowing an agent to isolate hosts, disable accounts or block network ranges without human approval is tempting, especially out of hours. But a confident, wrong action on a production system can cause an outage that rivals the incident it was meant to stop. Where automated response is justified, it should be narrowly scoped, reversible and governed by deterministic rules, not open-ended model reasoning.

• Poor data, poor agent. If your logging is incomplete, your asset inventory is stale and your identity data is inconsistent, an agent will reason fluently over bad information and produce plausible but wrong conclusions. Agentic AI amplifies the quality of your data; it does not repair it.

• Novel, high-stakes judgement. Deciding whether an incident is reportable under NIS2, DORA or the GDPR, whether to involve law enforcement, or how to communicate with a regulator requires legal and business context that agents should support, not own.

• Replacing junior analysts entirely. Organisations that remove the entry-level layer lose the pipeline that produces tomorrow's senior investigators. I advise using agents to make junior analysts more effective, and to teach them, rather than to eliminate them.

The new risks you are introducing

An agent with tool access is a privileged identity in your environment, and it must be treated as one. Several risks deserve attention before anything goes into production.

Prompt injection. Security agents by their nature read attacker-controlled content: phishing emails, malicious documents, log entries, web pages. Any of these can contain text crafted to manipulate the agent into ignoring instructions, leaking data or taking unintended actions. This is not theoretical; it is an inherent property of systems that mix instructions and untrusted data in the same input. Defences include strict separation of untrusted content, least-privilege tool access and human approval for consequential actions.

Excessive permissions. It is common to see agents connected to tools with the same broad rights as a senior administrator. An agent that only needs to read EDR telemetry should not be able to push policy changes.

Data exposure. Case data often contains personal data, credentials and sensitive business information. You need clarity on where prompts and outputs are processed and stored, who can access them, and whether that is compatible with your GDPR obligations and contractual commitments.

Hallucinated certainty. Language models can state incorrect conclusions with complete confidence. Agents should be required to cite the specific evidence, queries and results behind each conclusion so that a reviewer can verify them quickly.

How I recommend deploying it

The approach that has worked best for the teams I advise is deliberately incremental.

• Start read-only. Begin with enrichment, summarisation and query drafting, where the agent can observe but not change anything.

• Measure against your own baseline. Track how agent-assisted cases compare with unassisted ones on accuracy, time to disposition and analyst workload, using your own data rather than vendor claims.

• Log everything the agent does. Every tool call, query, input and output should be recorded and reviewable, both for quality assurance and for any later investigation or audit.

• Add actions with approval gates. When you introduce write actions, require explicit human approval, and limit them to reversible operations first.

• Red-team the agent. Test it with adversarial inputs, including injected instructions in emails and documents, before attackers do.

• Govern it like any other critical system. Under NIS2 and DORA, AI tooling in your security operations is part of your ICT risk landscape, and it should be within scope of your risk assessment, change management and third-party oversight.

What this means for security leaders

The organisations getting real value from agentic AI are not the ones with the most autonomous deployments. They are the ones that started with clean data and clear processes, chose narrow use cases with measurable outcomes, kept humans accountable for decisions and treated the agent itself as an attack surface. That is less exciting than the marketing, but it is what holds up in production.

My advice to CISOs and boards is simple: invest in agentic AI as a force multiplier for skilled people, not as a substitute for them, and insist on the same discipline of least privilege, logging and oversight that you would demand of any human with the same access. Done that way, it is one of the most meaningful improvements to security operations I have seen in years.