Tenable CyberAgents Exchange Turns Security Agents Into Shared Infrastructure

Tenable launched CyberAgents Exchange at Black Hat USA as a free, open-source registry for cybersecurity AI agents, skills, MCP servers, and playbooks. The useful idea is shared defense code; the hard part is proving each component is trustworthy enough to run inside real security operations.
Tenable logo on a white background
Tenable logo. Image: Wikimedia Commons / public domain text logo.

Tenable used Black Hat USA 2026 to launch CyberAgents Exchange, a free, open-source registry where security teams can find and contribute AI agents, reusable skills, Model Context Protocol servers, and multi-agent playbooks built for cybersecurity work.

The announcement is not just another vendor adding an AI assistant to a security console. CyberAgents Exchange is closer to an open directory for defensive automation: listings point to source repositories, contributors submit entries through pull requests, and teams can inspect the code and metadata before deciding whether a component belongs anywhere near their environment.

That matters because agentic security is moving quickly from demo language into operational tooling. Tenable says the exchange launched with more than 50 open-source components, including a command-line agent for Tenable One vulnerability management workflows, a SentinelOne Purple AI MCP server, a Recorded Future skill for mapping MITRE ATT&CK paths against live findings, Tenable’s SOC-Hunter threat-hunting skill, and a multi-agent exposure-management playbook called The Hounds Pack.

The launch also gives the industry a useful test case: whether AI security agents can be shared more like detection rules and less like opaque SaaS features.

What Tenable Is Actually Offering

CyberAgents Exchange is not a marketplace where users download bundled binaries from Tenable. The public GitHub repository describes it as a content source for listings. The actual agent code stays in each contributor’s own public repository, while the exchange stores metadata and descriptions for four types of content: agents, skills, MCP servers, and playbooks.

That structure is important. A security team evaluating an AI agent needs to know more than what it claims to automate. It needs to know who built it, where the code lives, what license applies, what tools or accounts it touches, what outputs it produces, and what limits are documented. Tenable’s repository requires submitted projects to have an open-source license, no secrets in git history, and a README covering purpose, prerequisites, usage, outputs, and known limitations.

Listings are reviewed through a validator and maintainer process before publication. According to the repository, each listing is a markdown file with YAML frontmatter, and automated checks validate required fields, controlled vocabularies, and file placement. That does not make a listed component safe by default, but it does create a baseline that ordinary copy-and-paste automation lacks.

The timing is deliberate. Black Hat USA 2026 ran August 1 through August 6 in Las Vegas, with the main conference and Business Hall landing just as AI security tools became one of the dominant themes of the event. Tenable also tied the launch to SWARM, a multi-day build event at Black Hat sponsored by AWS and supported by Anthropic, where practitioners built open-source security agents, skill files, and MCP servers.

Why A Shared Agent Directory Could Help Defenders

Security teams already share threat intelligence, Sigma rules, YARA rules, detection logic, vulnerability checks, and incident-response scripts. Agentic security adds a more complicated object to that pattern: a tool that may reason across systems, call APIs, enrich alerts, query vulnerability data, create tickets, summarize logs, or chain several actions into a workflow.

Building those components in isolation is expensive and risky. One team may write an agent to prioritize internet-exposed vulnerabilities against active exploitation data. Another may build a similar workflow for cloud posture findings. A third may connect the same intelligence feed to a different ticketing system. Without a place to compare and reuse work, every organization repeats basic integration and safety decisions privately.

A public exchange can lower that duplication if it remains genuinely inspectable. MCP servers are a good example. They can make security data available to AI tools, but they also create a new permission surface. A poorly designed server can expose too much data, accept unsafe inputs, or give an agent broader access than the use case requires. A directory that forces contributors to document scope, dependencies, and source code gives security teams a better starting point than a random repository link passed around in a chat thread.

Playbooks raise the stakes further. A single-agent tool may answer a question or run a focused check. A multi-agent playbook can coordinate several steps, such as gathering exposure data, mapping likely attack paths, validating exploitability, drafting remediation tickets, and producing an audit report. That is useful only if the organization can see where human approval belongs and which actions are read-only, advisory, or capable of changing systems.

The Trust Problem Does Not Disappear

Open source makes agentic security easier to inspect, but it does not remove the need for internal review. Security teams should treat exchange listings as starting points, not approved software. Before running an agent, teams still need to review the source repository, pin versions, scan dependencies, test in a sandbox, restrict credentials, log tool calls, and verify what data leaves the environment.

The same caution applies to skills for AI coding assistants. A reusable skill that helps analyze vulnerabilities or write detection logic may be valuable, but it can also shape prompts, choose files, or influence generated code in subtle ways. Teams should inspect skill instructions just as carefully as scripts, especially when they affect incident response, remediation, or production configuration.

The repository’s own model points in that direction. It requires public repositories and documentation, but it also makes clear that the exchange is a directory rather than a code host. That means trust remains distributed: Tenable provides platform and review infrastructure, contributors own their code, and adopting organizations decide what is safe enough for their environment.

What To Watch Next

The strongest signal will be whether CyberAgents Exchange grows beyond Tenable-centered workflows. SentinelOne and Recorded Future joined as founding members, and their participation gives the project a better chance of becoming a cross-vendor hub rather than a branded catalog. The difference will show up in the mix of contributors, the quality of documentation, the speed of review, and whether components keep working as security APIs and AI clients change.

For enterprises, the practical question is not whether they should let autonomous agents run security operations unsupervised. They should not. The more useful question is whether they can reuse audited, source-visible automation for the parts of security work that are repetitive, evidence-driven, and easy to constrain.

If the exchange succeeds, it could make defensive AI agents more legible. Security leaders would still need governance, testing, and approval workflows, but they would be evaluating visible components instead of one-off internal experiments or sealed vendor features. That is a healthier path for agentic security: shared infrastructure where the code, provenance, and limits are part of the product.

Leave a Reply

Your email address will not be published. Required fields are marked *

Previous Post
The White House exterior, used for coverage of the 2026 AI cybersecurity executive order.

White House AI Review Rules Put Frontier Models Behind a Private Gate

Related Posts