AI agents. They’re everywhere. There are adverts for them on TV, on public transport, and even in stadiums.
For security professionals, they’re inescapable: nearly every vendor is trying to sell a product that uses them, to the point that the term has almost lost its meaning.
So, security practitioners have started building, configuring, and operating their own agentic AI for security.
Custom-built agents fill the gaps that off-the-shelf tools can’t. Open-source, vendor-neutral AI agents can go a long way towards strengthening collective defense. But without proper governance, they can do more harm than good.
Why are security teams building and sharing their own agents?
There are three main reasons security teams are building their own agents: AI agents work, custom-built ones work better, and open-source agents strengthen collective defense.
Why use AI agents in the first place?
Despite the hype, agentic AI for security delivers results.
According to the Verizon DBIR 2026, organizations face 50% more CISA KEV vulnerabilities to remediate than a year ago. With vulnerability counts rising, security teams need to find, prioritize, and close them faster than ever. AI agents can help them do that.
An agentic AI system can correlate, prioritize, and in some cases even remediate flaws without human intervention. That dramatically brings down mean time-to-respond (MTTR) – an urgent priority considering the same report found that the median time-to-patch for CISA KEV vulnerabilities rose from 32 days to 43 days year-over-year.
Why build your own AI agents?
Off-the-shelf tools rarely meet business-specific requirements. Generic AI agents often have context gaps, lack adequate controls and guardrails, and present intent drift.
Practitioners build their own agents to address these shortcomings.
They build them with deep integration into their security architecture and local telemetry. They include strict tool allow-lists and hard execution boundaries. Custom-building loops allow for tighter human-in-the-loop approval gates. Finally, Model Context Protocol (MCP) servers connect those agents to tools.
Why share AI agents?
An MCP server – by far the dominant agentic protocol with over 10,000 active servers and 7 million monthly downloads – is also what makes agents vendor neutral and shareable.
A practitioner can write an MCP server for, say, a specific detection tool, without needing a vendor to ship that integration. Similarly, practitioners across teams and even organizations can pick up and run MCP servers built by one of their peers.
Sharing AI agents in this way strengthens collective defense the way open-source threat intelligence does.
With open-source threat intelligence, security teams get the information they need to close a vulnerability or thwart an attack.
Open-source agentic AI for security takes that a step further, giving teams a ready-made tool that can do the work rather than requiring them to build one from scratch.
Solving the AI agent governance problem
For all the benefits, however, practitioners cannot just go around spinning up AI agents without oversight. These are not chatbots that merely generate text – they execute actions.
When an agent can autonomously write code, query data stores, and change network configurations without human permission, unstructured sharing or unmonitored use introduces severe operational risk.
Multiply that risk across entire ecosystems, even entire industries, and the potential for abuse is enormous and unignorable.
So, what must governance look like before you can grant agents write access?
First, apply the principle of least privilege – as a starting condition, not an afterthought.
The easy way to deploy agents is to just grant them access to everything and let them have at it. But that introduces unnecessary risk. Granting agents access only to what is absolutely necessary prevents unintended consequences elsewhere in the business.
Then, introduce human-in-the-loop checkpoints for the highest-impact actions.
You can generally trust agents to complete low-impact actions (like alert triage and log correlation) without signing off, because a mistake won’t cause too much harm. Mistaken high-impact actions, like write actions against production systems, can bring a business to its knees. That makes human sign-off essential.
Finally, agents must be auditable. Good audit trails for security agents log not just what action was taken, but why the agent decided to take it, what it touched, and who approved it. That should be captured in tamper-evident, queryable records a human can review after the fact.
How can teams measure whether AI agents are paying off?
Although the underlying code and logic for shared AI agents are often free, running and securing them isn’t. So, you need to make sure they’re worth the effort.
That means measuring them against concrete outcome metrics. Has your MTTR fallen? Have you reduced analyst triage load? Are you missing fewer high-severity findings? These are some of the questions you need to be asking yourself and your team.
Where are open-source AI agents headed?
As practitioners become more comfortable building their own agentic AI for security, you’ll likely see many more of these tools emerge. Online exchanges will grow more popular, and collective defense will benefit.
However, disaster is not out of the realm of possibility. A rogue open-source agent can, and likely will, result in enormous operational disruption or breaches.
That’s why governance is so important, and why you need to be choosy about the ones you implement.