CyberAgents Exchange is a pattern library, not an install list

BLUF: CyberAgents Exchange is a free, public directory of defensive AI components. I did not install any of them. I pulled every linked GitHub repo through GitHub’s API, read the contribution rules, and sampled the listings that are not just another Tenable API wrapper. The useful move is we find inspiration for our ideas — evidence over model memory, compute outside the LLM, human gates before writes — then rebuild those habits for a stack we actually own. A badge on a listing is not a change-control board.

I have no commercial relationship with Tenable, SentinelOne, or Recorded Future. This is a practitioner first look, not a product review, and not a how-to for dropping these components into production.

What it actually is

Tenable launched this at Black Hat USA 2026 (press note, 4 August; SWARM recap, 7 August). SentinelOne and Recorded Future joined as founding members. I like the shape of the idea. Defenders rebuild the same glue in private, then lose it. A cyber-native directory is overdue.

It is still an index, not an app store. Listing metadata lives in tenable/cyberagents-exchange. The code stays in each author’s public GitHub repo. You always fetch from the author.

Four kinds of listing:

KindWhat it is
AgentsStandalone tools that automate a security task
SkillsSKILL.md packs for Claude Code, Cursor, and similar assistants
MCP serversTool servers that expose a product API to an agent
PlaybooksMulti-step chains that name which agents/skills run in what order

Free to list, free to use. Submissions go through validator.py, gitleaks on the linked repo, and two Tenable maintainer reviews. Their own checklist calls that a baseline look for overt malice and “does the README match the repo” — not a security audit. Tiers for “community reviewed” and “Tenable vetted” are still criteria TBD. Every listing I saw is contributed. That matters more than the launch language about peer-supported status.

What I actually reviewed

I did not clone 96 repos onto a box and run them. I enumerated every listing file (97 markdown files → 96 unique GitHub repositories), pulled stars, language, license, and last push, and read READMEs on the ones that looked vendor-neutral or methodologically interesting.

That is enough to talk about shape. It is not a blessing that any of this is safe to run.

Counts as of 25 August 2026:

  • 97 listings: 20 agents, 55 skills, 17 MCP servers, 5 playbooks
  • 96 unique public repos, all reachable
  • Star mass is concentrated. packetchaos/navi (97 stars, since 2019) and Sentinel-One/purple-mcp (94 stars, since 2025) are real tools that predate the directory. Sentinel-One/ai-siem (69) is a parser/detection library. Most of the rest sit at 0–12 stars. The exchange repo itself is 11 stars and 43 forks — people contributing, not a crowd of operators
  • About half are Python. A lot of skills are markdown-only. That is normal for Claude/Cursor. It also means a lot of “agents” are procedure packs, not daemons
  • Tenable gravity is real. The README even says “Best on Tenable One, but built for all.” Fine. It is not a universal SOC catalog yet

I could not find anyone who independently ran the exchange in production and wrote it up. Coverage is the launch kit, reprints, and one trade piece that lands the right warning: shared defense code is the idea; trust is still on you. Contributor issues asking for last-updated dates and provenance are a better signal than the press quotes.

Do not confuse this with cyberagent.exchange. Different product, similar name.

Everybody’s stack is different

That is the whole argument. One person is running Wazuh in a lab they own. Another has Tenable One and a cloud CNAPP. A third is a laptop and whatever came with the day job. An MCP server that speaks Tenable’s API is dead weight until you have that tenant. A Claude skill that assumes Hexa is not a Cursor skill until you rewrite the tool names.

So “install from the exchange” is the wrong first move. The right one is the same move we already use for Sigma: read the method, keep the invariants, rewrite the adapters.

Public MIT/Apache code is there to be learned from. Pasting a stranger’s MCP into a live SIEM with production keys is not learning. It is an unreviewed privilege boundary with a nice README.

Patterns from the listings (without installing them)

These showed up in listings I actually read. They are not unique to Tenable. They are how you keep an agent honest.

1. Evidence over recall. Vuln Analyst (Ash Collins) refuses to state EPSS, KEV, or affected versions from model memory. It fetches, cites, and dates the data, then walks CISA SSVC. Browser extension, CLI, or skills. No scanner required. I like that a lot. Vulnerability data changes daily. The model should not be the encyclopedia.

2. Arithmetic in code, not in the model. Tenable Activity MCP is Tenable-specific. The design is not: do not hand an LLM 40,000 audit events and ask it to count. Roll up in Python. Return findings with evidence and the threshold that fired.

3. Rank fixes, not findings. Chokepoint Finder (SWARM 1st place, Team Vauban) groups findings by the shared change that retires them, then ranks by marginal coverage. The MCP ships a deterministic demo estate with no credentials. Writes wait for a human. Zero stars today — treat it as a published method, not a mature product. The demo-estate idea is the part I would copy in spirit: prove the loop before you attach keys.

4. Key-free local caches for intel. Threat Intel Toolkit aggregates free feeds into SQLite on the operator’s machine. No API keys. Defanged IOCs accepted. Hash reputation is out of scope because the reputable free hash feeds now want a key. A CLEAN result is not proof of safety. Honest limitations beat a fake “complete intel platform.”

5. Static-only analysis. Tacklebox triages reported phish without executing attachments or visiting URLs. Offline layers first; VirusTotal / URLScan optional.

6. Propose, then confirm. Navi’s Claude skills treat tag/ACR/scan writes as propose-then-approve. The Hounds default NAVI_ALLOW_WRITES=0. That is the correct default for anything that can change a tenant.

SOC-Hunter’s LOCK loop (Learn → Observe → Check → Keep) is the same idea for hunting: hypothesis and gates, not “just query everything.”

If you only take one sentence: the model should not be the system of record, and it should not be the change-control board.

What this is not (yet)

  • A cross-vendor app store. Founding members help. The long tail is still Tenable-shaped.
  • Peer-supported in the sense the marketing uses that phrase. The live tier is contributed.
  • A substitute for pinning commits, reviewing dependencies, and running in a lab that cannot reach production identity.
  • Something I have operated. SWARM winners published in 48 hours against synthetic estates. That is a feature of the event, not evidence of Monday-morning use.

Casey Reid’s navi is the exception: seven years of CLI, then MCP and skills on top of a local SQLite copy of your data. The exchange indexed work that already existed. Most listings are newer and thinner. I would rather take a year of boring CLI than a weekend of autonomous SOC.

Potential — a personal lab, not a shopping list

The interesting follow-on, for me, is a personal lab: ingest, enrich, detect, hunt, and report against systems I own, with those same invariants. That is a project to design. It is not a weekend git clone.

I would not install exchange components into that lab as-is. I would use the public repos as a reading list:

  • SSVC + live EPSS/KEV/NVD for vuln research notes
  • Local, key-free IOC lookup for defanged indicators in public reporting
  • Hunt files with a LOCK-style gate so sessions leave artifacts
  • Adapters only for tools I actually run (a Wazuh box is the kind of example I mean — not a vendor tenant I do not have)
  • Human approval before any write path

Everybody will build that differently. That is the point. The exchange’s value is that defenders can finally see how other people encoded those habits — skills, MCP tool surfaces, playbook stage files — instead of starting from a blank editor every time.

If the directory lasts, watch whether non-Tenable listings keep landing, whether “last updated” reflects the source repo (an open request from a contributor), and whether tier 2/3 ever mean something you can defend to a CISO.

Open questions

  • Which of these patterns survive a year of API drift without a maintainer?
  • Can a lab that does not speak Tenable still get leverage from the skill/MCP shape alone?
  • When (if ever) a community-reviewed tier is more than a label.

How to look without installing

Browse exchange.tenable.com. For any listing you care about, open the linked GitHub repo, read the README limitations, and stop there until you have a lab that cannot reach production credentials.

The site also publishes two JSON indexes: agents.json and playbooks.json. You do not need them to browse. They are the same catalog in a form a script or an AI assistant can read — name, author, GitHub URL, tags — without scraping every listing page. I used that shape of data to count repos. Humans can ignore the JSON and click the website.

Sources