Kirsten Doyle |
The model is the easy part of an AI agent
With the advancement of large language models (LLMs) and artificial intelligence (AI) agents in recent years, building effective AI tooling for cybersecurity teams is becoming drastically easier. But getting them to work safely and consistently with the security tools you already run is still no easy task.
Picture what a vulnerability management team wants from an agent: pull findings from three scanners, check each asset against threat intelligence, work out which fix removes the most risk, and drop the answer into the ticketing queue. Every step touches a different system. If each connection needs its own integration, you’ve built a maintenance burden before the agent does anything useful.
That’s the problem open source AI agents, Model Context Protocol (MCP) servers, and reusable skills are starting to solve. They let security teams standardize those connections and reuse work someone else has already done and published. The large language model (LLM) behind the agent is only one part of the system, and increasingly it’s the least differentiated part.
The large language model (LLM) behind the agent is only one part of that system.
Why does MCP matter to security teams?
MCP is an open standard for connecting AI applications to external tools and data sources. For security teams, its value rests on a fact of life: no security environment comes from one vendor. An agent working on even a single vulnerability might need to reach:
• Vulnerability scanners
• Cloud platforms
• Identity systems
• Code security tools
• Ticketing systems
• Threat intelligence feeds
• Asset inventories
Without a common protocol, each of those is a bespoke integration, and it breaks the moment you introduce a second agent or swap the underlying model. An MCP server exposes a tool’s capabilities through one consistent interface. Any agent that speaks the protocol can use them, and nobody rebuilds the connection per agent.
The practical payoff is choice. You decide how agents connect to your tooling, rather than inheriting whatever integration layer a single supplier ships. Vendor-neutral isn’t a feature, it’s the whole point.
How are agentic skills different from MCP servers?
An MCP server connects an agent to a tool. A skill tells the agent how to do a job. The distinction matters because the two are reusable separately.
Take vulnerability prioritization. An MCP server gives the agent access to vulnerability and asset data. A skill holds the instructions the agent follows to analyze that data and decide which remediation actions come first. Any agent that picks up the skill inherits the process, and a team that swaps its scanner keeps the skill and changes only the server.
Black Hat USA 2026 showed how this can work in practice. Participants built MCP servers around tools they already used and turned common security tasks into skills that other practitioners could reuse. The first-place project, Chokepoint Finder, ranks fixes rather than findings: it groups vulnerabilities by the action that resolves them and computes the shortest ordered list that removes the most weighted risk.
The team released it in four forms: an agent, an MCP server, a skill, and a playbook. That’s the point of the four forms. You don’t have to adopt the whole project. Use the skill with your own agent, or point the MCP server at your existing setup, and leave the rest.
This gives other security teams a useful starting point without requiring them to design, build, and deploy the whole project from scratch.
What changes when agentic security components become reusable?
Security teams have automated repetitive work for years, but much of that work stays inside the organization that created it.
A team might write a script to reconcile findings from two scanners or develop a workflow for checking whether a vulnerability has already been mitigated. Other teams facing the same problem often build their own version.
Sharing those components gives practitioners somewhere else to start.
Open registries for agentic AI for cybersecurity provide a place to share agents, MCP servers, skills, and multi-agent playbooks. Source repositories also give practitioners the opportunity to inspect and adapt components before using them.
Teams do not have to adopt someone else’s entire agentic system to benefit from that work. An MCP server that connects to a commonly used security tool can have value on its own. So can a skill that captures a useful vulnerability management process.
Teams can combine those components with their existing tools and replace individual parts as their requirements change. They are less likely to find that useful integration work or security expertise only works inside one proprietary environment.
Can security teams trust open source AI agents?
Access to source code gives security teams more information about what an agentic component does, but they still need to decide whether it is safe to run in their environment.
That assessment becomes more complicated when an agent combines MCP servers, skills, and other components that different people created. Each component can introduce permissions, dependencies, and access to additional systems.
Before deploying an agent, teams need to understand where it came from, what it can access, and what actions it is allowed to perform. An MCP server that only retrieves vulnerability data brings a different level of risk from one that lets an agent change configurations or trigger remediation.
Least privilege can restrict agents to the systems and permissions they need for a particular task. High-impact actions, especially changes to production systems, should require human approval.
Teams also need records of what an agent did. Logs should show the actions it took, the information it used, and any approval required before execution. Those records become particularly useful when teams need to investigate an unexpected action involving several shared components.
Open source gives practitioners the opportunity to inspect code and provenance before deployment. Their own access controls, approval requirements, and testing still determine how much authority that code receives.
How can open source AI agents improve collective defense?
Cybersecurity practitioners already share work across organizational boundaries. Threat intelligence, vulnerability information, detection rules, indicators of compromise, and open source security tools all allow one team to benefit from work done elsewhere.
Agentic components add security processes and integrations to what practitioners can share.
A team investigating a vulnerability could reuse a skill that another practitioner developed, rather than recreating the process. An MCP server could provide the connection to a security tool that the agent needs along the way. Teams can then adapt those components to their own tools, permissions, and approval processes.
Vulnerability management offers plenty of opportunities for this kind of reuse. Teams across different organizations reconcile findings between systems, prioritize remediation, validate fixes, and move information into other operational workflows.
As more of these components become available, security teams will need to decide what they are comfortable bringing into their environments and under what conditions.
Kirsten Doyle has been in the technology journalism and editing space for nearly 24 years, during which time she has developed a great love for all aspects of technology, as well as words themselves. Her experience spans B2B tech, with a lot of focus on cybersecurity, cloud, enterprise, digital transformation, and data centre. Her specialties are in news, thought leadership, features, white papers, and PR writing, and she is an experienced editor for both print and online publications. She is also a regular writer at Bora.
30 Oct 2026
29 Oct 2026
23 Oct 2026
22 Oct 2026
How open source AI agents, skills, and MCP servers are reshaping cybersecurity defense – iTWire
Leave a Comment
