Before You Install an MCP Server on Faith, Run This Free Three-Question Security Check

Note: Tenable and OpenAI announced the CyberAgents Exchange AI Inspector on September 3, 2026, at OpenAI’s “Intelligence at Work: Cyber Summit” — four days old as of this writing. The tool itself is expected to roll out through September 2026, so parts of what’s described below are landing over the next few weeks, not all live on day one.

Here’s a question worth asking honestly: the last time you installed an MCP server, an agent skill, or a “playbook” someone posted to a community registry, what did you actually check before you ran it? If the answer is “it had a lot of stars” or “someone on a forum said it worked,” you’re not alone — and until this week, there wasn’t really a better option unless you were willing to read the source yourself, which almost nobody does for a tool they’re installing to save time.

On September 3, Tenable and OpenAI announced the CyberAgents Exchange AI Inspector: a security review process built specifically for AI agents, skills, MCP servers, and multi-agent playbooks, layering OpenAI’s GPT cyber models, Tenable’s own exposure-management tooling, and human researcher review on top of the CyberAgents Exchange — an open-source, cybersecurity-native registry for these components that Tenable launched in August 2026 and which already holds more than 100 community-submitted entries.

The honest version of this story has two parts. Part one: this is a genuinely useful piece of infrastructure for exactly the problem it targets — “should I trust this thing a stranger built and put in a public registry” — and it’s arriving because that problem has gotten real enough that a company like Tenable is betting a product on it. Part two: the actual Inspector is aimed at enterprise security teams with Tenable One subscriptions, and most readers of this site aren’t going to have it in front of them by name. What you can take from this, usefully, today, is the three-question framework it’s built on — because that framework works whether or not you’re paying for the tool that automates it.

What actually got announced, and what it isn’t yet

Date	Event
August 2026	Tenable launches the CyberAgents Exchange — an open-source registry for AI agents, skills, MCP servers, and multi-agent playbooks
Black Hat USA, August 2026	A SWARM build event drives community contributions; the Exchange crosses 100 submitted components
September 3, 2026	Tenable and OpenAI announce the CyberAgents Exchange AI Inspector at OpenAI’s Cyber Summit
September 2026 (ongoing)	Inspector functionality rolls out; not everything described in the announcement is live simultaneously

Sources: Tenable’s official press release, GlobeNewswire’s syndication of the same release, StockTitan’s coverage including market reaction.

Worth being precise about what this is not: it is not a scanner you run against your own codebase, and it is not (yet) a public database of “safe” vs. “flagged” ratings you can browse for free before installing something. It’s a review pipeline for components submitted to the Exchange, aimed at the enterprise security teams who are the actual customers deciding whether to let those components into their environments.

The three-layer review, and why each layer exists

The Inspector runs submitted AI components — agents, skills, MCP servers, multi-agent playbooks — through three distinct checks before a security team is expected to trust them:

1. Frontier assessment using OpenAI’s GPT cyber models. An AI model specifically tuned for security analysis reads the component’s code and behavior for the kind of thing a human reviewer would flag on a good day: unusual network calls, credential handling that doesn’t match the stated purpose, prompt-injection surface area.
2. Skills inspection via Tenable One AI Exposure. Tenable’s own exposure-management platform maps what the component can actually reach and touch once installed — permissions, data flows, downstream systems — the same category of analysis Tenable already sells for traditional attack-surface management, extended to cover AI-specific artifacts.
3. Expert human review from Tenable researchers. The part that doesn’t scale, and the part that catches what the first two miss — judgment calls about intent, context, and the kind of subtle social-engineering-flavored code that reads fine to a model but wrong to a person who’s seen the pattern before.

Tenable’s chief product officer, Eric Doerr, framed the motivation directly: “Agentic AI will only reach its potential in the enterprise if security teams can trust the components being introduced into their environments.” That’s a fair statement of the actual problem, and it’s the same problem a five-person shop has when someone on the team finds an MCP server on GitHub that does exactly what they need and installs it before lunch.

The partnership itself didn’t come out of nowhere — Tenable has been part of OpenAI’s Daybreak Defense Network, a group of security vendors OpenAI works with directly on frontier-model-assisted defense, and the Exchange Inspector is the first shipped product to come out of that relationship rather than a one-off integration bolted on after the fact. That matters for how durable this is likely to be: it’s not a press-release partnership, it’s a product built by two companies that already had a working relationship on the underlying models.

This isn’t hypothetical — MCP servers are already being weaponized

It’s worth being specific about what “risk” means here instead of leaving it abstract, because the pattern is no longer theoretical. Security researchers have documented several real MCP-specific attacks in 2026 that show exactly why a review layer like this exists:

• The handshake attack. Researchers at Morphisec traced a malicious npm package called drp-compliance-sdk, published as a fake SOX/compliance verification tool. Once installed and registered as an MCP server, the payload fired automatically during the initial protocol handshake — the tools/list call every MCP client makes on connect — before a user ever typed a prompt or invoked a tool. The execution chain used only signed Microsoft binaries (a living-off-the-land technique), and it didn’t trip any behavioral signature across five independent security tools that were watching.
• The unsanitized parameter. A well-starred, widely-used Figma MCP server (tracked as CVE-2025-53967) passed a fileKey parameter straight into child_process.exec without sanitizing it first — meaning anyone who could control that file key could get shell execution on the machine running the server. High star count, real usage, real vulnerability sitting in plain sight until someone looked.
• Tool description poisoning. Instead of hiding malicious code in the server’s actual logic, attackers hide extra instructions inside the tool description text itself — the metadata an agent reads to decide what a tool does and how to call it. A poisoned description can quietly instruct the agent to run something like cat ~/.ssh/id_rsa as a “diagnostic step,” and a model reading it at face value has no inherent reason to treat that instruction differently than a legitimate one.
• Delayed-trigger payloads. A campaign researchers nicknamed “Deadbugz” went further still: the malicious behavior stayed dormant through the first two tool calls and only activated on the third, specifically to defeat the kind of quick manual test — “let me try it once and see what happens” — that passes for review in most small shops.

None of these four required a sophisticated attacker with zero-day tooling. They required a publisher willing to wait, a plausible-looking README, and an installer who didn’t check permission scope against stated purpose. That’s the exact gap the manual three-layer check below is built to close.

Why this is really a supply-chain story wearing an AI costume

If the shape of this sounds familiar, it should. Software has been fighting a version of this exact problem since package registries existed — npm, PyPI, RubyGems, all of them have spent years building scanning, signing, and reputation systems for the same underlying risk: a component published by someone you’ve never met, doing something you didn’t fully verify, running with more access than you’d grant to a stranger if you thought about it directly.

MCP servers, agent skills, and multi-agent playbooks are the same risk pattern with a new name and a shorter track record. The registries are younger, the scanning tools are younger, and — this is the part that should actually worry a small shop more than the enterprise headline does — the audience installing them skews toward people who are excited about a new capability and moving fast, which is exactly the audience least likely to have a review process in place already.

The sandbox-is-a-policy piece from August covered a related failure: even Anthropic and OpenAI’s own internal evaluation environments had permission mismatches that let models reach real systems they weren’t supposed to reach. That was about runtime isolation — the walls around an agent once it’s running. This story is upstream of that: it’s about whether the thing you’re about to let inside the walls deserves to be there in the first place. Both matter, and most small shops currently have neither in any formal sense.

The part that matters if you can’t afford the enterprise tool

Here’s the uncomfortable honesty this piece owes you: Tenable One, the platform underneath the “skills inspection” layer, is an enterprise exposure-management product with enterprise pricing. The Inspector as Tenable is building it is not going to be a free button a two-person shop clicks before installing an MCP server off GitHub. If your business doesn’t already have a security budget with a line item for a platform like this, you’re not the customer, and waiting for this specific tool to trickle down to your price point isn’t a plan.

What is usable, today, without buying anything, is the three-question shape of the review itself — translated into something you can actually run by hand in fifteen minutes before you install a community-built agent component:

A manual version of the three-layer check

Layer	What Tenable/OpenAI automate	What you can do instead
Frontier/model assessment	GPT cyber model reads code for anomalies	Paste the component’s source into any capable coding-agent chat and explicitly ask it to review for unusual network calls, credential handling, and prompt-injection surface — this works surprisingly well as a first pass, even without a security-tuned model
Exposure/permission mapping	Tenable One maps what it can reach	Read the actual permission scopes it requests (API keys, file system access, network egress) and ask “does this match what the tool claims to do” — a component that asks for more than its stated job needs is the single clearest red flag in this whole exercise
Expert human judgment	Tenable researchers review	This is the one you can’t fully outsource. Read who published it, how long the account/repo has existed, whether it has any real usage history beyond a star count, and whether anyone else has reported issues — five minutes of due diligence most people skip entirely

None of this replaces a real vetted registry with institutional review behind it. It closes the gap between “zero review” — which is where most small shops actually are right now — and “some review,” which catches an embarrassing amount of the obviously bad stuff without costing anything.

What a real registry with review actually solves, when it matures

It’s worth being fair to the direction this is heading, not just skeptical of the current gap. A cybersecurity-native registry with layered review, if it matures the way npm’s and PyPI’s scanning ecosystems eventually did, changes the economics of the decision. Right now, “review it yourself” is the only option for a component with no track record, and that review takes real time most people don’t spend. A registry with a visible review status — even an imperfect one — turns “did anyone check this” from a question you have to personally answer into a fact you can look up, the same way a package’s download count and maintenance history became a rough (imperfect, gameable, but genuinely useful) trust signal for npm packages over the last decade.

The 100+ components already in the Exchange after one Black Hat build event suggests there’s real community interest in participating on the supply side too — publishers who want a “reviewed” badge next to their skill or MCP server, not just users who want to consume one safely. That two-sided incentive is usually what makes these ecosystems actually stick, rather than becoming a well-intentioned registry nobody uses because submission is a hassle and review takes months.

Where this connects to what you’re already doing wrong

If you’ve read the stateless MCP piece or the agent liability blast-radius checklist from earlier this year, this story slots directly into both. Stateless MCP made agent tools deployable by one person — which is a genuine unlock, and also means the barrier to “install this thing that does something powerful” dropped at the exact moment the barrier to “verify this thing is safe” did not drop with it. The blast-radius piece covered what happens when a compromised or malicious agent component gets real access: the deployer eats the consequences, not the vendor, and not the anonymous contributor who published the MCP server.

Put those two pieces together and the Tenable/OpenAI announcement reads less like enterprise security news and more like an admission that the industry has noticed the exact gap this site has been pointing at: it got easy to deploy agent tooling before it got easy to verify it. The review process is enterprise-first because enterprise budgets fund product development first — that’s not a criticism of Tenable, it’s just how this always goes. The manual checklist above is the interim version for everyone else, until (if) something like this actually reaches a price point a small shop can use directly.

A worked example: the MCP server that looked fine

Concrete scenario, because “review your dependencies” is abstract advice until it’s a specific decision. A three-person agency finds an MCP server on a community registry that connects a coding agent directly to their client billing system — pull invoices, check payment status, flag overdue accounts, exactly the kind of unglamorous automation this site is built around recommending. It has a clean README, 40 stars, and a maintainer who’s clearly put real effort into documentation.

Running the manual three-layer check: First, the permission scope. The MCP server requests read and write access to the billing API, even though every use case in the README only describes reading data. That’s the single clearest flag in the whole exercise — a request for more access than the stated purpose needs. Second, pasting the server’s source into a coding-agent chat with an explicit “review this for anything that doesn’t match its stated purpose” prompt surfaces a webhook call to an external logging endpoint that isn’t mentioned anywhere in the documentation — possibly benign telemetry, possibly not, but not disclosed either way. Third, checking the publisher: a GitHub account created two months ago, this is its only public repository, and there’s no other project history to establish a track record.

None of these three things individually proves malice. Together, they’re exactly the pattern that should stop a five-minute “sure, let’s try it” installation and turn it into either a request for read-only access specifically, a direct question to the maintainer about the logging endpoint, or a decision to build the narrower integration in-house instead. That’s the entire value of running even an informal version of this checklist: it turns a blind trust decision into an informed one, in less time than it takes to actually integrate the tool.

When you genuinely don’t need to bother with any of this

If the MCP server or skill is published by the platform vendor itself — Anthropic’s own MCP servers, an official integration from a tool you already pay for — the vetting bar is lower. You’re extending existing trust in a vendor relationship, not evaluating a stranger.

If the component only touches data you’d be comfortable posting publicly. A skill that formats text or does math with no external data access has a small enough blast radius that the fifteen-minute check is overkill. Save the scrutiny for components touching credentials, customer data, or write access to real systems.

If you’re prototyping locally with no real data or credentials wired in. Testing something in an isolated environment before deciding whether to use it for real is exactly the right instinct, and it doesn’t need the full checklist — the checklist matters before you connect it to anything that actually matters.

Bottom line

Tenable and OpenAI built a genuinely sensible piece of infrastructure for a problem that’s been quietly getting worse: AI agent components are exploding in number, published by people with wildly varying levels of trustworthiness, and installed by teams moving fast enough to skip the review step every other software supply chain eventually learned it needed. Most readers of this site won’t be Tenable One customers, and that’s fine — the three-question shape underneath the product (does the permission scope match the stated purpose, does an independent read of the code find anything undisclosed, does the publisher have any track record at all) is free, takes fifteen minutes, and catches more than doing nothing, which is the actual comparison that matters for a small shop deciding whether to bother.

Sources

All facts accessed September 7, 2026.

• Official announcement, three-layer review structure, and Eric Doerr quote — Tenable press release, “Tenable Uses OpenAI GPT Cyber Models to Help Defenders Inspect Community-Built AI Components”
• Full release syndication and additional confirmation of timeline — GlobeNewswire, September 3, 2026
• CyberAgents Exchange component count, SWARM build event details, and market reaction data — StockTitan, “Tenable Uses OpenAI GPT Cyber Models to Help Defenders Inspect…”
• Additional framing on the launch context and Cyber Summit venue — The Fast Mode, “Tenable, OpenAI Launch AI Security Review Process for CyberAgents”
• drp-compliance-sdk handshake-triggered MCP supply-chain attack — Morphisec, “MCP Supply Chain Attack via a Malicious Compliance SDK”
• Figma MCP server unsanitized fileKey vulnerability (CVE-2025-53967) and tool-description poisoning technique — Securelist, “Model Context Protocol for AI Integration Abused in Supply Chain Attacks”
• Delayed-trigger “Deadbugz” campaign details — Adversa AI, “Top MCP Security Resources, September 2026”