Exchange Inspector: Designing Verification for AI Components

Finding an AI agent or skill in a public registry and pulling the publisher’s code into your own environment is becoming a real way to source software.

This approach is convenient, but deploying a component without first reviewing its behavior and required permissions could create a new entry point for attackers.

The security industry has now put forward one concrete response to that problem.

What Tenable and OpenAI announced: inspecting components before use

On September 3, 2026, the security company Tenable announced the CyberAgents Exchange AI Inspector — Exchange Inspector — developed in collaboration with OpenAI.

Unveiled at OpenAI’s Intelligence at Work: Cyber Summit, the effort is described as having grown out of Tenable’s participation in OpenAI’s Daybreak Defense Network.

It builds on the CyberAgents Exchange, which launched in August 2026.

The Exchange is a community-driven, cybersecurity-focused directory of AI agents, AI skills, MCP servers, and “playbooks” that chain multiple agents together. Following SWARM, an event held at Black Hat USA, Tenable reported that it had more than 100 listings.

One detail is worth pausing on: what the Exchange holds is listing metadata. The actual code lives in the publisher’s own GitHub repository.

In other words, you find a component on the Exchange and then obtain it from the publisher’s repository.

Exchange Inspector is intended to inspect these components before use.

Tenable describes it as combining assessment by OpenAI’s GPT cyber models, skills inspection powered by Tenable One AI Exposure, and review by Tenable’s own researchers.

At the time of the announcement, availability was planned for sometime in September 2026.

The announcement does not specify the order in which the methods are applied, what each method covers, or how findings are evaluated and reported.

Tenable’s stated position is that trust in the components being brought in matters if enterprise adoption is going to expand.

Being listed and being inspected are not the same thing

Separately from Exchange Inspector, the CyberAgents Exchange has a review step at the point of listing.

According to the published contribution guide, automated validation of the listing metadata is accompanied by maintainer checks: that the linked repository is public, that the license is valid, that no secrets appear in the repository’s history, and that the description matches what the repository actually contains.

Once a listing is accepted, the publisher can display a “Listed on CyberAgents Exchange” badge in their own README.

That badge indicates that the component is listed. It is not described as indicating an Exchange Inspector result.

Being listed, having undergone a review, and being appropriate for your company to adopt are three separate things.

How to use an external inspection result in an adoption decision

What has been announced is a design: a combination of three methods.

Evidence of how much the inspection actually catches was not presented, at least not at the time of the announcement.

To assess detection performance, you would need to know the conditions under which it was evaluated and what the results were.

The question this news raises, then, is what a company should do with a component that comes with an external inspection result attached.

Our view: connect external inspection results to usage conditions and ongoing review

We treat external inspection results as useful input for an adoption decision.

What we want to establish is what was inspected, when, by which methods and under which conditions — and whether the inspected version and configuration match what we plan to run.

For the Exchange, this means checking that the inspection results apply to the version obtained from the publisher’s repository.

And AI mistakes are not the only thing to prepare for.

Defects in the external component itself, vulnerabilities in the software it depends on, and malicious modification by a third party all belong in the same discussion.

The OWASP Gen AI Security Project, in its treatment of generative AI supply chain risk, also covers outdated components, tampering by third parties, and the maintenance of a component inventory such as an SBOM.

In our view, managing these risks requires both inspection and operational controls.

The potential harm and the controls needed depend on the data a component handles, the actions it is allowed to take, and the scope of its autonomous operation. They also depend on how readily execution can be stopped, how easily normal operation can be restored, and how quickly problems are detected.

To take an example: using a component to analyze security logs and present findings is not the same as having it act on those findings and isolate an endpoint. The permissions required and the approval conditions differ.

Even when a component is granted access only to logs, check which information it can read and where it can send that information.

This is a comparison we are drawing between two kinds of use; it is not a description of any particular product listed on the Exchange.

When adopting a component, document its version, intended use, permitted operations, and the rationale for adoption. Then implement those conditions through access controls and approval settings.

Once the component is in use, review execution results and repeat the relevant checks when the component or a dependency is updated, a connection or permission changes, or a new issue is identified.

Plan these steps together from the outset, linking external inspection and internal adoption decisions with operational controls and ongoing review.

Three areas to review

Checking external inspection information, deciding whether to use something in your own environment, and monitoring and reviewing it in operation involve different participants and decisions.

The following is an example set of checks, to be made specific to your own operations, the data you handle, and the rules that apply to you.

Review area	What to check or decide	Relevant systems, processes, and records (examples)
External inspection results	The inspected version, inspection date, methods, conditions, and findings; whether the results apply to the version you plan to run	Publisher documentation, inspection results, internal component inventory
Use in your environment	Intended use, data handled, permitted operations, approval requirements, and stop conditions; whether the restrictions are enforced in practice	Security review, access controls, connected APIs, approval workflows
Operational monitoring and review	Who reviews execution records, who is responsible for stopping execution and managing recovery, and which updates or permission changes trigger reassessment	Logging and monitoring infrastructure, change management, operating procedures

Each review area may involve several systems and processes.

The decision to adopt may be made internally while the permission restriction is enforced on the connected system; assigning responsibility for stopping execution in an internal policy still requires a technical means of stopping it.

Use external inspection results to inform the adoption decision, and supplement them with the checks and controls required for your own deployment.

Practical caveats

This article deals with the design of checks and operations for bringing in externally published AI agents and AI skills. Review processes for agents a company builds in-house are outside its scope.

Exchange Inspector was also, as of the announcement, not yet available.

As of this writing, we have not found an official notice confirming that it has since become available.

We see the proposed combination of methods as a way to inform adoption decisions, not as proof of safety.

Conclusion

Exchange Inspector is intended to make inspection of community-built AI components part of the adoption process.

At MIF, we focus on comparing the scope and findings of an external inspection with the version, intended use, and permissions of the planned deployment. Document the adoption decision and configure access controls and approval requirements accordingly. Reassess them when components are updated or the scope of use changes.

Before adopting a component, define who approves its use, which operations are permitted, and which changes trigger reassessment.

Sources and Verification

This article was prepared as of September 2026, drawing primarily on the press release Tenable published on September 3, 2026, with supplementary reference to the official CyberAgents Exchange overview page and its contribution guide.

In framing the risks, it also draws on the security risk categories published by the OWASP Gen AI Security Project.

The number of listings on the CyberAgents Exchange, the timing and inspection methods of Exchange Inspector, and the operation of the listing review are all subject to change.

Statements about the product are based on published material; MIF has not independently verified detection performance or security.

The discussion of internal adoption decisions and ongoing operation reflects MIF’s own analysis and recommendations.

For any adoption decision, please consult each company’s current official information.