AIR Security Raises $50M: What Automated Vetting Solves — and What It Can't Yet

Yesterday, AIR Security came out of stealth with $50M across two seed rounds — $10M led by Sequoia and $40M led by Greenoaks — to build security tooling for the skills, plugins, and MCP servers that AI agents install. We work in the same corner of the industry: we're the Correctover team, building the open-source verification tools at github.com/Correctover. So our mentions lit up. Here's our read — what happened, why the numbers matter, what automated filtering genuinely fixes, and where it structurally stops.

A supply chain nobody is watching

When coding agents started reaching for third-party components on their own initiative, a new software supply chain formed — one assembled at runtime. As Sequoia's announcement post puts it, an agent consumes "skills, plugins, MCP servers, sub-agents, hooks, commands and rules — each running with the agent's own permissions, inside a user's environment, against a user's data," usually "installed with the care most of us would give a browser extension."

The exposure numbers reported this week are worth sitting with:

• More than 17,800 public AI add-ons, accounting for 6.7 million installations, drew instructions from outside sources nobody had verified, according to SiliconAngle.
• AIR says its platform currently filters out roughly 27% of the add-ons and skills it finds online, per TechCrunch's reporting.
• AIR's own research, summarized in Sequoia's post, found 925 live skills pulling dependencies and prompts from dead links; registering those expired links put roughly 134,000 installed agents under outside control. In a separate experiment, a researcher-built malicious skill reached 26,000+ agents through a trusted marketplace and social media — and every scanner it passed through cleared it.

The mental model AIR's CEO Yair Saban offers is driver signing: in the early 2000s, drivers didn't need signatures; today every driver tells you who signed it, because it loads code into the kernel. Skills and MCP servers load instructions into an agent that holds your credentials — and there's no equivalent signature check yet, as TechCrunch reports.

That's why the category is drawing capital. Tens of thousands of components, millions of installs, and the components keep changing after install.

What the automated layer actually solves

The playbook emerging across this category — discovery, static analysis, dependency checks, sandbox detonation, runtime interception, allowlists — tracks closely with what AIR describes across its product line (Sequoia). It's worth being precise about what this machinery is good at, because it's a lot:

• Static analysis catches hardcoded credentials, unexplained network calls, and declared permissions that don't match what the component claims to do.
• Dependency checks catch the dead-link and typosquatting families — the SkillJacking pattern above is fundamentally a dependency-integrity failure.
• Sandbox detonation watches what a component actually does when run: callback domains, file access, child processes.
• Runtime interception blocks installs or calls that fail policy in the moment, instead of trusting a one-time review.
• Continuous re-verification handles drift. A skill that passed review in March can be rewritten in June by its maintainer — or by whoever took over the maintainer's account. Sequoia's Bogomil Balkansky told TechCrunch: "This is not a scanning problem, it is a continuous re-verification problem."

At 17,800+ components and growing, none of this can be human-scale. Automation isn't a nice-to-have here. It's the only thing that can cover the surface.

Where automation structurally stops

Here's the part we spend our days on, and where we'd push the conversation further. Automated filtering produces verdicts at scale, but three classes of problem resist it structurally — not because any vendor's implementation is weak, but because of what the questions themselves require.

1. Semantic intent in minified or obfuscated code. Heuristics and sandbox runs depend on signals. A minified or deliberately obfuscated payload strips them: the code might be a harmless bundled build artifact, or a dropper that only activates under conditions the sandbox never reproduces — a specific date, a specific tenant, a specific prompt. Determining intent means reading code in context, the way a human reviewer does. Detonation answers "what did it do in the lab?" It can't fully answer "what would it do on my machine, on Tuesday, with my data?"

2. Business-logic-level tool abuse. The hardest calls aren't malicious components — they're legitimate components used in illegitimate ways. A CRM plugin with a documented bulk-export feature is doing exactly what it says on the tin when an agent exports 40,000 contacts to a personal email. Every individual tool call is well-formed, permitted, and benign-looking. "This agent may read accounts but never bulk-export" isn't a universal signature. It's your organization's policy, and judging it requires understanding your business context, not just the bytes in flight.

3. Evidence for procurement and compliance. A pass/fail flag is a signal, not a record. When a security questionnaire asks "what was checked, when, on which exact version, under which rule set, and who signed the verdict?" you need an archivable artifact — a receipt that binds the verdict to the exact input bytes, tamper-evident and re-verifiable months later. This is the same gap application security filled by moving from "the scanner said fine" toward signed attestations and SBOMs. Signals protect the moment; evidence survives the audit.

None of this is a knock on automated platforms. You need the filter before you can afford the review. It's the same division of labor as SAST/DAST versus manual code review versus attestation: layers, not substitutes.

Make your component cheap to audit

If you publish skills or MCP servers, the practical lesson is that vetting is moving from "someone might glance at this" to "a pipeline will decide whether enterprises can install this." Your job is to make the pipeline's job easy:

• Least privilege, declared explicitly. Ship a permission manifest. Read-only by default, scoped tokens, no inherited environment variables you don't actually use. A component that asks for everything gets blocked; a component that asks for one documented endpoint gets read.
• Verifiable provenance. Pin and hash your dependencies. Sign releases. Never fetch instructions, prompts, or rules from arbitrary URLs at runtime — that's the entire SkillJacking failure mode. If you must load remote content, pin it to a content hash.
• Reproducible builds. Ship the artifact auditors can actually read. Minified server blobs force every reviewer to treat you as opaque; source maps and reproducible build instructions let static analysis see what you are.
• Write your security posture down. A SECURITY.md — or a security section in your README — that states what you access, what network calls you make, where data goes, and how to report issues earns more trust than any badge. Vetting cost is what gets components rejected. Lower yours.

If you run agents, start with the cheap layer today:

# Scan MCP configs in the current directory — no credentials, no network
npx correctover-scan

# Or wire it into CI with SARIF output
npx correctover-scan -d . -f sarif > mcp-audit.sarif

Where we fit

We're Correctover, and we build open-source verification tooling plus an audit methodology for this space — not a platform, not a marketplace. correctover-scan runs local config and static checks. Our MCP verification gateway (ccs-mcp-server, with correctover-mcp-server available if you'd rather transparently wrap a server you already run) sits in front of tool calls, fails closed, and writes an Ed25519-signed receipt for every decision — the evidence artifact described above. The decision path is deterministic, with no model call in the loop: sub-millisecond on the core verification hot path, because verification you can't afford to leave on in development isn't verification.

Everything lives at github.com/Correctover. Try it against your own agent setup, and please open issues — false positives are bugs, and a call we allowed that shouldn't have been is the most valuable report we can receive.

A $50M vote of confidence in this category is good news for anyone shipping agents. It means "where did this component come from, and who checked it?" is finally becoming a budgeted question. The next step is making sure every answer comes with evidence.