Security Review Process

How we think about trust

The Exchange is a directory, not a distribution channel. Contributors keep their code in their own public GitHub repositories, and a listing from here points back to it. That design is the foundation of every trust decision on the site, and it comes with a few principles we hold:

• Trust through transparency. No bundled binaries, no compiled drops, no black boxes. Every listing resolves to its public source, so that you can inspect the build in its entirety, line by line.
• Open source license, required. Every listing carries a permissive open-source license (MIT recommended, Apache 2.0, and others welcome), declared with its SPDX identifier.
• The bar is the same for everyone. Tenable's own listings and partner listings go through the same security review process as community listings, reviewed by people independent of the contribution.
• Always free. There are never any fees to list.

How security reviews work

Every submission arrives as a pull request against the CyberAgents Exchange's GitHub repository and moves through the same path:

• Automated submission screening. Before anyone reads the submission, we scan the linked repository's full git history for committed secrets, confirm it carries a detectable open source license, and confirm it's public, active, and reachable. Any failure stops the review.
• Baseline review by two Tenable reviewers. Two Tenable employees work through the public contributing checklist independently, item by item, as sequential GitHub reviews. They confirm the listing describes the repository it points to, that the install instructions actually work, and that nothing in the repository is overtly malicious, deceptive, or unauthorized. When both approve, the listing goes live at the Contributed tier. Anything short of that goes back to the submitter as a change request with specific feedback.
• Deeper review for selected listings. Tenable selects listings for review by the CyberAgents Exchange AI Inspector, a three-stage security review that combines automated inspection, frontier model assessment, and expert human review. A listing that clears all three stages earns the Exchange Inspector vetted tag.
• Ongoing monitoring. Every Exchange Inspector Vetted review is anchored to a commit. When submissions have material changes from their reviewed commit, they will be resubmitted for another review.

The decision log for every review is the GitHub pull request itself, so the record of what was checked and who approved it stays public.

Trust tiers

Every listing shows its tier next to its name. There are two today:

• Contributed. Automated secret, license, and repository screening, then a baseline review by two Tenable reviewers for accuracy and overtly malicious behavior.
• Exchange Inspector Vetted. Everything in Contributed, plus a three-stage security review by Tenable One AI Exposure, OpenAI GPT cyber models, and Tenable security researchers, anchored to a specific commit and backed by a written review record. This is the highest level of review on the Exchange.

Tier 1: Contributed

Every listing starts here. It's a baseline review, not a comprehensive security audit.

It confirms the listing adheres to structural and coding standards and is free of overt problems. It doesn't mean a component is free from defects, vulnerabilities, or unintended functionality. Further, it doesn't examine the code's full attack surface.

Every listing must successfully pass the following checks to be added to the CyberAgents Exchange. Whether the listing is an AI agent, skill, MCP server, or playbook, it must meet the same minimum standards and clear three layers of review:

• Automated screening. We scan the linked repository's full git history for committed secrets and confirm that the repository is public, active, and carries an open-source license. A committed credential is an automatic rejection, even if it's been rotated.
• Listing review. Two Tenable reviewers independently confirm the listing matches the repository it points to: what it does, what it integrates with, how to install it, and every claim in its description. Install instructions have to be real and followable, not generic.
• Baseline behavioral review. Reviewers check the repository for overtly malicious, deceptive, or unauthorized behavior and re-check the hard lines below against the actual code.

All contributed reviews on the Exchange are anchored to a specific commit.

Tier 2: Exchange Inspector Vetted

The “Exchange Inspector Vetted” tag is the highest level of review a listing can currently receive. It means the listing passed a full security vetting process by the CyberAgents Exchange AI Inspector (aka, “Exchange Inspector”), engineered by Tenable to incorporate the logic of OpenAI's frontier GPT cyber models as part of the Daybreak Defense Network.

Exchange Inspector vetting builds on the Contributed review rather than replacing it, performing in-depth code screening over three stages:

• Automated inspection with Tenable One AI Exposure. The skills inspection engine in Tenable One AI Exposure parses the agent's instructions, the tools it can invoke, and the data it can reach, and flags prompt injection and jailbreak attempts, hidden or invisible instructions, hardcoded secrets, PII exposure, and sensitive data access. It's the fast, repeatable pass: it clears the obviously safe, blocks the obviously unsafe, and hands everything else forward with its findings attached.
• Frontier assessment with OpenAI GPT cyber models. The models read the source and look for ways the component could be abused, beyond matching known threats. They ask three questions: Can untrusted content reach the model? If the agent were hijacked, what could it do with the tools it has? Do steps that look harmless on their own add up to something harmful when chained together? Higher-risk and dual-use submissions go to more capable, purpose-trained models. If a model refuses to review a submission, we treat that as a review signal, not a pass.
• Expert review and runtime verification by Tenable security researchers. Researchers validate the automated and frontier findings, write a threat model for the component, review security-relevant surfaces in the source, assess the trustworthiness of the repository owner and maintainers, and install and run the component in a clean, isolated environment using only its documented setup steps. Observed behavior is compared with what the documentation claims, and any discrepancy is a finding.

Want the same inspection for the agents already running in your environment? Request a demo of Tenable One AI Exposure →

Rejected at any tier

Some things end a review immediately, regardless of tier or how well they're built:

• Offensive or weaponized components designed to exploit, move laterally, or exfiltrate data
• Hardcoded secrets anywhere in the linked repository's git history
• Undisclosed outbound calls. Every outbound data flow must be documented in the linked repository
• Competitor targeting, meaning anything designed to disrupt or surveil a third party
• Weakening security controls, such as disabling logging, EDR, or firewalls without justification

These are re-checked against the actual code at every tier, and no accepted risk or documented rationale can override them.

A review covers one version of the code

A Git repository is a living codebase, so every review is anchored to a specific commit, and the listing shows the date of the last review. The review covers that commit only. It's not a standing approval of a branch, a future release, or the repository as a whole.

Contributors keep their code and can make changes to their listings at any time. When material code changes are made to an Exchange Inspected listing, the new build version may require another review to ensure no new flaws have been introduced and that appropriate controls remain in place. Such material changes may include, but are not limited to:

• Authentication or authorization behavior, or required permissions and API scopes
• Network destinations, telemetry, or data handling
• Prompts, system instructions, tools, resources, or playbook steps
• Dependencies, lockfiles, build scripts, install scripts, or release artifacts
• Filesystem access, process execution, or export behavior
• Tenable product integration, or read versus write capability
• Any security finding that changes the previous risk decision

When a listing is removed

Tenable reserves the right to remove any listing at any point in time, and may decline future contributions from builders who are found to violate the guidelines set in the CyberAgents Contribution Agreement, publish listings that contain malicious code, or act in bad faith or otherwise breach the spirit of the guiding tenets of the Exchange.

A listing with a repository that goes private, appears to be abandoned or unmaintained over an extended time period, is archived, or is no longer attributable to the listed owner will also be removed. Removal removes the listing from the directory; it doesn't touch the contributor's repository.

What a trust tier isn't

A trust tier describes the review a listing received at a point in time. It isn't a warranty, a certification, or an endorsement of the contributor, and it doesn't replace your own review before you run a component against production systems or data.

The Exchange is a directory: the code you install comes from the contributor's repository, under the contributor's license, and you're responsible for evaluating it against your own environment and policies.

For contributors: preparing for the review

The fastest path through any review is a repository that already answers the reviewer's questions. Before you submit, and especially if you'd like your listing considered for vetting:

• Document every outbound destination, every permission or API scope, and every state-changing action, and make the README match the code
• Keep the install path installable from source, with pinned dependencies, and put any archive's contents in unpacked form at the repository root
• Ship from a versioned release tag rather than a moving branch
• Keep secrets out of git history entirely; rotating a leaked key doesn't remove it from the history we scan
• Prefer read-only defaults and explicit confirmation for anything that writes, deletes, or changes configuration
• Complete your contributor profile on the Exchange and link it to a verified Discord username

The full checklist reviewers work from is public in the contributing checklist, and the submission steps are on the Contribute page.