Agent Governance After AIR's $50M: What to Do Now

By Lazar Milicevic · Published October 29, 2026 · 11 min read

If you run agents with Claude Code, Cursor, or any MCP-based setup, you probably can't answer a simple question: which skills, plugins, and servers can your agents load right now, and who approved them? AIR just raised $50 million to sell that answer to enterprises. You can build a workable version of it yourself this week.

What AIR actually announced

AIR came out of stealth on September 1, 2026, with $50 million raised across two seed rounds, according to Top Tech News. The first was $10 million led by Sequoia Capital; the second was $40 million led by Greenoaks, with Swish, Netz, and several angels participating (The SaaS News). Coverage differs on round structure (one source describes a single co-led seed), so "two seed rounds, per TechCrunch's reporting" is the safest phrasing. The company was founded in February 2026 by CEO Yair Saban and CTO Niv Hoffman, both Unit 8200 veterans, and has about 40 employees (DevCuration).

The product has three parts, per Sequoia's write-up:

• Air Filter vets add-ons before an agent can use them: static analysis, dependency checks, and sandbox detonation.
• Air Defend monitors agent behavior at runtime.
• Air Control manages posture and policy, including revoking a bad skill across many agents at once.

There's also AIR Marketplace, a catalog of pre-vetted external and internal add-ons (GeethanTech). On the customer side, AIR reports more than 20 customers, roughly a quarter of them large enterprises, with financial services and pharma showing the strongest demand (MLQ.ai). Those numbers are self-reported.

In the sources I reviewed, no price or valuation was given, and the product is presented as an enterprise solution. But the problem it targets isn't enterprise-only.

The problem: your agents have a supply chain

An agent that loads a skill or MCP server is running someone else's instructions with your credentials. That's a software supply chain, except the "package" can include natural-language prompts that tell the model what to do, and those can change after you approved them.

AIR's own research shows why this matters. In "The Circus of Skills," AIR scanned 142,836 live skills and found 17,822 that fetch instructions from untrusted external sources, about 12.4% (AIR). Those skills account for 6.7M installations. Two caveats: this is AIR's own research, not independent, and the install total is based on roughly the 9,500 most popular skills on skills.sh.

Two other findings from AIR, as described by Sequoia:

• A researcher-built malicious skill reached more than 26,000 agents through a trusted marketplace and social media while every scanner cleared it.
• In "SkillJacking," AIR found 925 live skills pulling dependencies and prompts from dead links. AIR registered those links and gained control of roughly 134,000 agents that had installed the skills.

The second one is the pattern to internalize. The skill was fine when someone reviewed it. Later, a domain it referenced expired, and anyone could claim it. AIR says this is why it re-evaluates skills continuously: an approved skill can turn risky if a downloaded package changes or the developer's account is compromised (Stockpil).

The OWASP Agentic Skills Top 10 puts this in standard vocabulary. "Untrusted External Instructions" is AST05, rated High, with mitigations of source inventory, content pinning, and continuous rescanning. "No Governance" is AST09, rated Medium, with skill inventories and agentic identity controls as the fix (OWASP).

What you can take from AIR's architecture

You don't need the product to use the model. AIR's design maps to four controls:

The sections below cover each, in the order I'd do them.

Step 1: Inventory what's running

You can't govern what you haven't listed. Start by finding every place an agent config lives. Check each agent tool's documentation for where it stores MCP server definitions and permission settings, and look in both project-level and user-level locations.

# Find MCP and agent config files across your repos and home dir
find ~ -maxdepth 6 \( -name ".mcp.json" -o -name "mcp.json" \
  -o -name ".claude.json" \
  -o -name "settings.json" -path "*claude*" \
  -o -name "claude_desktop_config.json" \) 2>/dev/null

# Pull every declared MCP server command out of the ones you find
jq -r '.mcpServers // {} | to_entries[] | "\(.key)\t\(.value.command) \(.value.args|join(" "))"' .mcp.json

Then record what you find in a registry. This is the artifact everything else hangs off:

# agent-registry.yaml
agents:
  - id: invoice-triage
    owner: ops@yourcompany.com
    runtime: claude-code
    environment: production
    credentials: [gmail-readonly, quickbooks-readonly]
    tools:
      - name: gmail-mcp
        source: github.com/example/gmail-mcp
        pinned_commit: "<full-sha>"
        approved_by: lazar
        approved_on: 2026-10-29
        reviewed_scope: [read_messages, create_draft]
      - name: quickbooks-mcp
        source: internal
        pinned_commit: "<full-sha>"
        approved_by: lazar
        approved_on: 2026-10-29
        reviewed_scope: [read_invoices]

Include the shadow stuff. AIR's discovery layer specifically targets unapproved AI tools and personal accounts used for work. In a small team, that's the founder's personal ChatGPT or Claude account with a company Google Drive connected. Ask everyone to list every AI tool connected to company data. You'll find tools you didn't know existed.

Step 2: Vet before you install

Vetting at small scale means reading what you're about to give your agent. For each skill or MCP server, answer five questions:

1. Where do the instructions come from? Does the skill fetch prompts, scripts, or config from a URL at runtime? That is AST05 in one sentence.
2. Who owns those URLs? If the domain is expired or a personal repo with one maintainer, treat it as untrusted.
3. What does it do on install? Check for post-install scripts and dependency fetches.
4. What permissions does it request, and does the task need them? A calendar-summary skill with shell access fails this check.
5. Can I pin it? If you can't lock to a specific commit or hash, you can't know what you approved is what runs.

A quick triage script catches the most common red flags in a skill directory:

import re, pathlib, sys

# Patterns that suggest runtime-fetched instructions or code
RISKY = {
    "remote_fetch": re.compile(r"(curl|wget|requests\.get|fetch\()\s*.*https?://", re.I),
    "pipe_to_shell": re.compile(r"(curl|wget).*\|\s*(ba)?sh", re.I),
    "eval_exec": re.compile(r"\b(eval|exec)\s*\(", re.I),
    "raw_url_in_prompt": re.compile(r"(read|follow|load).{0,40}https?://", re.I),
}

def scan(skill_dir: str):
    findings = []
    for path in pathlib.Path(skill_dir).rglob("*"):
        if not path.is_file() or path.stat().st_size > 1_000_000:
            continue
        try:
            text = path.read_text(errors="ignore")
        except Exception:
            continue
        for name, pat in RISKY.items():
            for m in pat.finditer(text):
                findings.append((str(path), name, m.group(0)[:100]))
    return findings

if __name__ == "__main__":
    for f in scan(sys.argv[1]):
        print(" | ".join(f))

This is a triage filter, not a security product. It will miss obfuscated payloads and flag harmless code. AIR's sandbox detonation exists because static reading has limits, and the researcher-built skill that every scanner cleared is the reminder. Use the script to decide what deserves a careful human read, not to certify anything safe.

Step 3: Pin, then re-check on a schedule

Pinning is the cheapest control with the biggest payoff. OWASP names content pinning as a mitigation for AST05. Pin to a full commit SHA, not a branch or a floating tag:

{
  "mcpServers": {
    "gmail": {
      "command": "npx",
      "args": ["-y", "gmail-mcp@1.4.2"],
      "env": { "GMAIL_SCOPE": "readonly" }
    }
  }
}

Version pins like @1.4.2 help, but a registry can republish or an account can be compromised. For anything touching money or customer data, vendor the code into your repo or pin by commit hash and verify the content hash in CI.

Then handle the part AIR calls continuous re-evaluation. A nightly job that re-hashes approved tools and checks that every external URL they reference still resolves to the same owner covers the SkillJacking scenario:

import hashlib, pathlib, re, requests, yaml

URL = re.compile(r"https?://[^\s\"')>]+")

def tree_hash(path):
    h = hashlib.sha256()
    for p in sorted(pathlib.Path(path).rglob("*")):
        if p.is_file() and ".git" not in p.parts:
            h.update(p.read_bytes())
    return h.hexdigest()

def check_urls(path):
    dead = []
    for p in pathlib.Path(path).rglob("*"):
        if not p.is_file():
            continue
        for u in set(URL.findall(p.read_text(errors="ignore"))):
            try:
                r = requests.head(u, timeout=5, allow_redirects=True)
                if r.status_code >= 400:
                    dead.append((u, r.status_code))
            except requests.RequestException:
                dead.append((u, "unreachable"))
    return dead

registry = yaml.safe_load(open("agent-registry.yaml"))
# For each approved tool: compare tree_hash to stored hash, run check_urls,
# and alert (Slack/email) on any mismatch or dead link.

A dead link inside a skill you approved is exactly the condition AIR's SkillJacking research exploited. Treat it as an incident, not a warning. Remove the tool from the registry until someone reviews it.

Step 4: Enforce at runtime, not just at install

Vetting happens once; agents act continuously. AIR's enforcement layer intercepts actions such as loading a skill or fetching internet content and checks them against a whitelist (Stockpil). You can approximate this with three layers you already control:

Tool allowlists in the agent config. Deny by default and name what's permitted. Don't rely on the model to refuse.

Egress control. If the agent runs in a container or a dedicated machine, restrict outbound traffic to the domains it needs. A skill that tries to fetch instructions from a random domain then fails at the network layer regardless of what the prompt says.

# Example: run an agent container with outbound restricted to an allowlist proxy
docker run --rm \
  --network agent-net \
  -e HTTPS_PROXY=egress-proxy \
  -v "$PWD/agent-registry.yaml:/etc/agent/registry.yaml:ro" \
  your-agent-image
# egress-proxy config permits only: api.anthropic.com, your CRM domain, your mail API

Scoped credentials. Give each agent the narrowest token that works: read-only where possible, separate keys per agent, no shared admin credentials. If a skill is hijacked, the blast radius is whatever that agent's token can reach. This is the least glamorous control and the one that limits damage when everything else fails.

For anything with side effects (sending email, issuing refunds, writing to a database), add a human approval step or a hard rate limit. An agent that can draft is far safer than one that can send.

Step 5: Make revocation a single action

AIR's Air Control lets a team revoke a bad skill across many agents at once (Sequoia). The small-team version is a design rule: agents should read their approved tool list from one place, so removing a tool in one place removes it everywhere.

Concretely, generate each agent's config from the registry rather than hand-editing per-project files. When a skill is flagged, delete one entry, regenerate, redeploy. If your agents each have hand-edited configs scattered across laptops, revocation means hunting through machines while the bad skill keeps running.

Write the runbook before you need it:

1. Remove the tool from the registry.
2. Regenerate and redeploy agent configs.
3. Rotate any credential the agent held while the tool was active.
4. Review agent logs for the window the tool was loaded.
5. Record what happened and why in the registry history.

Step 3 is the one people skip. If a compromised skill ran with a live API key, assume the key is exposed.

Build, buy, or wait?

Honest assessment of the options:

Build the minimum yourself if you have a handful of agents and one or two people who own them. The registry, pinning, egress rules, and scoped credentials above cost days, not months, and cover the realistic risks.

Buy a platform when agent count, team size, or compliance pressure outgrows spreadsheets. AIR is one option; its coverage names Noma Security, Zenity, Astrix Security, and Operant AI as existing players with overlapping discovery, governance, and runtime-protection features (Tech Weekly). I'm not endorsing or comparing any of them here; check each vendor's site for current pricing and ask whether they serve teams your size.

Wait for the model vendors is a legitimate position with a catch. AIR's CEO acknowledged that AI labs and providers will likely add their own skill and tool checks, but expects companies to want an independent product that works across vendors (Tech Weekly). That's a vendor predicting its own market, so weigh it accordingly. But the cross-vendor point is real: if you use more than one model or tool, a vendor-native check covers only part of your surface.

One more caution on the numbers. AIR's 27% figure, the share of add-ons and skills it filters out, is the company's own claim, with no independent audit (Stockpil). Don't read it as an industry rate of malicious add-ons. The direction is credible; the precision isn't verified.

A one-week plan

• Day 1: Find every agent and AI tool touching company data. Fill the registry.
• Day 2: Read every skill and MCP server in it against the five vetting questions. Remove anything you can't justify.
• Day 3: Pin everything to versions or commits. Vendor anything high-risk.
• Day 4: Narrow credentials to read-only or per-agent scopes. Rotate anything shared.
• Day 5: Add egress restrictions and approval gates on side-effect actions.
• Day 6: Set up the nightly hash and dead-link check with alerts.
• Day 7: Write the revocation runbook and test it once on a harmless tool.

At the end you'll have an inventory, pinned dependencies, narrowed permissions, and a rehearsed response, which is most of what the enterprise tools sell, minus the dashboards and the sandbox.

Where this fits in AI automation work

Agent governance is now a funded product category, and the underlying work is unglamorous: inventory the MCP tools an agent can reach, vet the skills it loads, pin what was approved, and lock down what the agent is allowed to do in production.

If you're building your own agent setup, start with the one-week plan above and walk through what your agents can load, where it comes from, and what happens when something changes after approval.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.