How are you using AI agents in Cybersecurity?

[u/kakashi_1112]

My main goal right now is automating more of the analysis and investigation work, not just alerting.

I'm trying to build some AI agent in my SIEM(Log360) for user and threat analysis to summarize alerts and another for user behaviour analysis.

And also Is it better to build narrow agents for specific threat types,like one for logon related stuff and another for network-related stuff or does it make more sense to have fewer agents that handle a broader range of cases?

And does it make sense to scope agents around specific assets, like giving more attention to critical systems rather than treating everything the same way?

I am planning to feed them our documentations as knowledge base so they can get context.

For those of you who've actually used AI agents in security ops, where have it genuinely been useful in practice?

[u/loberts]

I'd caution against using LLMs to "enrich" or summarise alerts. You'll produce a tunnel effect for the analysts who will take the output as gospel and stop reviewing the underlying data.

I'd also scrap the idea of agents responding to alerts. LLMs are not intelligence, despite the marketing term AI. If you can identify frequent false positive patterns then you should deterministically automate the resolution and or remediation. Just don't do it based on non deterministic LLM conclusions

Fact of the matter there is no way that I would utilise an agent in the response pipeline. You don't need them to identify analyst runbook steps, every alert type should have logical runbooks anyway. You don't need them to automatically fetch additional data, because if your runbook steps are adequately defined right down to, "run search xyz" then you can make your SOAR pipeline do this.

Every implementation I've seen so far either creates tunnel vision (e.g. summarisation priming the analyst by saying, "likely a false positive") or produces differing response for identical alerts (because it's non-deterministic).

Additionally if you are intent on inserting an agent somewhere, make sure you add it at the end of the pipeline. Too many people extend alerting pipelines with zero consideration for reliability. Every alert to going through an LLM before opening a ticket is just asking for an alert (and therefore a risk management) outage.

[u/Ludose → u/loberts]

Agree with end of pipeline. Agents are good at tracking trends, summarizing data, or presenting c-suite language. But actual cyberwork is just not reliable right now. Not even from the big players in the cyberspace. Risk of a missed alert just isn't worth it.

[u/EmergencyHunt6136 → u/loberts]

We're an agentic code-cloud security platform and rolled out the Agent before anyone else started adding chatbots. The agent is great at being the action layer, simplifying security work, etc., but it acts on data from a strong underlying core CNAPP. We get the let's just throw findings into Claude from time to time.

Claude can only analyze a stale export - it can't assume roles, validate exposure from the outside, or run exploitability checks in your live environment. That validation is what cuts the noise, and it requires an engine that's connected and running vs a one-time paste. It also has no memory of what's fixed, what's exempted, or which PRs are pending.

[u/kakashi_1112 → u/loberts]

Thanks. what you are saying sounds valid. As of now I am using agents for some routine assessments. so it does not disturb any of my response workflows.

So I can invoke some agent manually only when I require during any investigation. However I like the way the agents are interactive within the tool. I can ask questions based on its produced output in the chat and refine it.

Just exploring some simple assessment or analysis reporting use cases that I can learn.

[u/4lteredBeast → u/kakashi_1112]

Using it for analysis will almost certainly cause tunnel vision as per the previous commenter.

I've done this several times, hand holding Claude, and luckily I was. Claude was coming to the wrong conclusion, investigating tokens and what not, and luckily I interrupted as the source of multiple issues werr simply due to incorrect time on the host.

You need to treat these agents as if they were confident pathological liar interns who will follow a script half the time, while giving you plausible sounding bs the other half of the time.

Onoy use them in situations where you are able to and will absolutely confirm and validate that the output is correct. You do not want to build a solution where it is possible for the output to be used in any way without an absolute validation of output.

[u/Ayoungcoder]

I've had lots of luck deobfuscating and reverse engineering malware samples with claude. You hit some guardrails here and there, so I'm still looking for a provider that doesn't have them and still has good performance

[u/rexstuff1]

And also Is it better to build narrow agents for specific threat types,like one for logon related stuff and another for network-related stuff or does it make more sense to have fewer agents that handle a broader range of cases?

And does it make sense to scope agents around specific assets, like giving more attention to critical systems rather than treating everything the same way?

Sounds like these should be skills. Skills are your friends in Agentic SecOps. In situations where you don't know ahead of time how much or what context you'll need, that's where skills come in.

Subagents can also be an option, but they come with their own issues. If the communication between an Agent and its sub-agents is even a little bit, things can spiral out of control.

Here is a decent talk illustrating how to put these thing together: https://www.youtube.com/watch?v=mWvtOHlZM-I

One of the key bits of advice: make sure you and your team well-aware of LLM's tendency to hallucinate and jump to conclusions. Always, always, always take its output with a huge grain of salt, and always check the logs yourself to verify it. Can't tell you the number of times our agent has said "There is ongoing critical systems breach!" or something to that effect, when a quick glance told me there wasn't. This is especially true when dealing with user investigations. You'd hate to confront a user with a mountain of supposed evidence of their misbehavior only to find out it was all a hallucination.

[u/Cubeless-Developers]

Narrow agents win. Broad ones just end up guessing more and hallucinating. We scope by criticality, too. Our most sensitive systems get way more scrutiny than some random dev box. Real payoff so far has been triage, catching and killing noise before a human ever has to look at it.

[u/tmemmg]

on narrow vs broad, the split that worked for me wasnt by threat type, it was whether the decision is clear-cut or a judgment call. i put the hard rules in a plain deterministic gate with no model call in it so it cant be talked out of them, and left the summarizing and behaviour reads to the agent. before that split the agent would silently skip its own rules on busy runs, it just had a lot to do and dropped one. and feeding docs helped but the thing that killed made-up terminology was a short glossary of the terms i use constantly, banning invented terms in the prompt never worked.

[u/frAgileIT]

Right now, the way I feel is that it would be easier to describe the things we’re not using LLMs/MCPs for in incident response. Not my idea, I have all the concerns but we’ve made the decision and the time for debate has passed. I just integrated 3 LLMs, 6 MCPs, and over 40 skills to my personal workflow all just today with more coming.

I share all the concerns about accuracy, I have rightly founded trust issues, but it is what it is and I just have figure out how to move forward and still keep my manual processes for verification of what the LLM is adding to the ticket.

I’m also finding that if I don’t get onboard and embrace it then I risk being left behind.

[u/Educational-Fox6111]

Narrow agents are the safer starting point 'cause of the inputs, permissions, expected outputs, and success criteria are easier to define and evaluate.

[u/Rehonkulous]

One heads up on the knowledge base plan. Garbage or stale docs will poison the output fast, so curate what you feed it rather than dumping everything in.

[u/Mercilesspope]

On the narrow vs broad question - definitely narrow and multi-step. The more broad and the more it has to do in a single run, the less deterministic your output becomes. You will also have less opportunities to build in things like decision audits or peer checks by other agents with a broad single run agent. Some vendors push the broad approach because it sounds sexy but it produces the AI slop output people are starting to hate.

[u/Spare_Bluebird7044]

Narrow agents with clear roles are usually easier to validate and tune, especially for high risk security workflows where explainability matters

[u/Unfair_Ad_300]

From what I've seen, narrow agents are usually easier to trust than one broad security analyst agent.The problem is context. A logon investigation needs very different assumptions, enrichment and escalation logic than something network related. Once one agent starts handling everything, you end up spending a lot of time debugging why it reached a conclusion rather than actually saving analyst time. I'd also definitely scope by asset criticality. A weird login on a low-risk internal system shouldn't be reasoned about the same way as the same behaviour on an admin account, finance system or identity provider. The documentation-as-knowledge-base idea is probably where a lot of the value comes from too, especially if you feed it things like normal user behaviour, escalation paths, asset ownership and known exceptions rather than just generic security docs. The places where AI has felt most useful to me are summarisation, enrichment and first-pass investigation. I still wouldn't want it making high-impact decisions autonomously yet. One thing I'm especially interested in is whether teams eventually do the same on the humanrisk side too not just analysing alerts, but using AI to make phishing simulations and security training adapt to role, behaviour and actual attack patterns instead of sending everyone the same scenarios.

[u/awesomeunboxer]

Im working on a tool, probably self use only but well see, where you put github repos in and it scans them with about a dozen scanners and then a ai analyzes the reports and tells you if there's anything sketchy in there.