An enterprise agent receives a request, selects a skill, calls an MCP server, loads a package, fetches outside content, and touches a company database. Each step expands the set of people and software trusted to act with the agent’s permissions.

AIR emerged from stealth on September 1 with a security platform built around that chain. The startup says it discovers agents inside companies, vets the skills and external components they use, and blocks interactions that fail its security criteria. It has raised $50 million across two seed rounds, according to TechCrunch.

AIR CEO Yair Saban told TechCrunch that the company currently filters out about 27% of the add-ons and skills it finds online. TechCrunch provides no sample size, discovery method, rejection criteria, false-positive rate, or independent validation, so the vendor-reported figure cannot be generalized to the broader ecosystem. AIR’s stated reason for continuous reinspection is narrower and better supported: a previously approved component can become risky if a package it downloads changes or its developer’s account is compromised.

For operators, agent inventory covers only the first stage of control. Policy also has to govern which dependencies an agent may load, what those dependencies may reach, and which changes trigger renewed review or suspended access.

The agent has inherited a supply chain

Skills, plug-ins, MCP servers, and add-ons extend what an agent can do. TechCrunch describes them as an emerging software supply chain that allows agents to interact with enterprise systems and the internet. Their operational value comes from access: a component can connect an agent to data, software, or an outside source that the base model could never reach alone.

That access creates a trust path from each outside component into the systems the agent can reach.

Saban compares the current agent stack with unsigned drivers in the early 2000s. Drivers eventually gained signature checks because they load privileged code. Skills, plug-ins, and MCP components can occupy a similar position around an agent, he argues, while lacking equivalent provenance controls. His analogy has limits. The TechCrunch report does not establish that every agent component executes like a kernel driver, and agent extensions vary in implementation and privilege. The shared feature is consequential delegation: the system accepts behavior supplied by another component and may carry that behavior into sensitive environments.

An approval process conducted once, during installation or procurement, misses two changes AIR explicitly identifies. A component may later download a different package. Its developer’s account may also be compromised. The name in the catalog can remain stable while the trust basis underneath it decays.

This makes the dependency graph temporal. Security teams need to know what an agent uses today, which version or package state was evaluated, when the evaluation occurred, and whether any material change should suspend access. A component cleared last month supplies weak evidence after its dependencies change this morning.

Four controls before execution

AIR’s product description suggests a four-stage enforcement path.

  1. Discovery: Find agents operating across the company, including employee use of unapproved tools or personal accounts.
  2. Dependency verification: Evaluate the skills, tools, MCP servers, plug-ins, and add-ons those agents attempt to use.
  3. Permission checks: Compare each proposed interaction with AIR’s maintained allowlist and the organization’s security criteria.
  4. Runtime enforcement: Hook into the agent, intercept actions such as loading a skill or fetching internet content, and block the interaction when it fails policy.

Discovery produces an inventory. Continuous vetting tracks the moving component set. The enforcement layer makes the result binding at the moment an agent acts.

That sequence closes a common governance gap. A security dashboard may accurately report that an agent and an MCP server exist while leaving the agent free to call the server. AIR’s design connects observation to a control point inside the execution flow, according to TechCrunch’s account. The block decision can occur when the agent loads a skill, fetches outside content, or reaches software that falls outside the accepted set.

The runtime hook carries its own engineering burden. It has to observe enough context to identify the component and proposed action, apply current policy before execution, and cover the agent fleet consistently. The article gives no latency measurements, supported-agent list, bypass analysis, or deployment architecture. Those omissions leave buyers unable to judge how completely the enforcement point sits between an agent and its dependencies.

Coverage determines the layer’s practical value. Any route that bypasses inspection remains outside its verdicts, so buyers need evidence of path coverage and fail-closed behavior.

The 27% figure has an unspecified denominator

AIR says it filters out about 27% of the add-ons and skills it finds online. The disclosed figure has no sample size, discovery method, rejection taxonomy, false-positive rate, false-negative rate, or independent validation. It is a vendor-reported result from an unspecified population and cannot support an estimated failure rate for public agent components.

Buyers should ask AIR to disclose the evaluated population, rejection categories and validation results. Independently of the percentage, privileged agents warrant explicit limits on approved components, permitted actions and reachable destinations.

AIR’s reinspection process is more consequential than the headline rejection rate. Initial screening catches the component AIR sees at that moment. Reinspection addresses package changes and compromised developer accounts after approval. In practical terms, an allowlist entry needs an attached condition: approval remains valid only while the evaluated component state and provenance remain within policy.

A static list cannot express that by itself. Operators need an enforcement system that can withdraw approval, propagate the changed verdict across the agent fleet, and stop new calls without waiting for each application owner to update local configuration.

Identity and inventory leave a gap

The agent-security market already contains products for discovery, identity, access control, runtime monitoring, and MCP gateways. TechCrunch names Noma Security, Zenity, Astrix Security, and Operant AI as companies operating across parts of this category. In the same September 1, 2026 report, TechCrunch says Zenity raised a $125 million Series C in August 2026 and Noma raised a $100 million Series B in 2025.

AIR is betting that continuous component vetting can separate it from that field. Saban describes endpoint visibility as comparatively easy to reproduce and argues that repeatedly evaluating skills and plug-in sites is harder. Sequoia partner Bogomil Balkansky calls the task an infrastructure problem: every skill, plug-in, MCP server, and sub-agent must be inspected again whenever it changes, across the full enterprise fleet and in real time.

Both statements come from parties invested in AIR’s success. AIR has yet to disclose enough evidence in the TechCrunch report to establish the claimed technical lead.

The underlying control gap exists regardless of AIR’s marketing claims. Identity systems can establish which agent made a request. Endpoint inventory can locate the agent. Access controls can define broad permissions. Each leaves a dangerous question unanswered when an agent delegates work to an external component: does the organization still trust the exact dependency involved in this action, in its current state? The Signal’s agent gateway explainer describes the adjacent control point for tools and credentials, while its survey of 7,000 MCP servers shows how quickly component-level risk can spread across a public ecosystem.

Agent identity and dependency trust belong in the same decision. An approved agent using an unapproved skill should fail. An approved skill attempting an unapproved destination should fail. A previously approved component whose package changed should return to review. Runtime enforcement is where those conditions converge.

The operator decision

AIR claims more than 20 customers, roughly one-quarter of them large enterprises. Saban says demand has been strongest in financial services and pharmaceuticals, two heavily regulated sectors. The article supplies no customer names, deployment sizes, case studies, or measured incident reductions, so the commercial evidence remains early and largely self-reported.

Buyers can still use the launch to sharpen their requirements.

First, map the full execution chain for each production agent: the agent, its skills, plug-ins, MCP servers, downloaded packages, software destinations, and outside content sources. Personal accounts and employee-selected AI tools belong in the discovery scope because AIR says its visibility product searches for both.

Second, attach policy to actions. “Approved MCP server” is too coarse when the server can expose several tools or destinations. The runtime decision should reflect what the agent is attempting, where the request will go, and which component supplied the capability.

Third, make component approval revocable. Package changes and developer-account compromise are explicit reasons for reinspection in AIR’s model. An operator should require a defined trigger for reevaluation, a method for distributing the new verdict, and a block path that works before the next interaction.

Fourth, test enforcement failure. AIR says its layer hooks into agents and intercepts activity. A procurement review should ask which agents and execution paths the hook covers, what happens when the service becomes unavailable, how local or embedded tools are handled, and whether an agent can reach enterprise software through an unmonitored route. TechCrunch provides no answers to those questions.

Fifth, separate vendor intelligence from company policy. AIR maintains an allowlist and also operates a marketplace of vetted skills and add-ons. That arrangement can reduce duplicate review work, but an external verdict cannot encode every company’s data boundaries, contractual limits, or acceptable destinations. The vendor can supply component intelligence. The enterprise still owns permission and enforcement policy.

AIR spans component vetting and enforcement

The company was founded by CEO Yair Saban and CTO Niv Hoffman, both veterans of Israel’s Unit 8200 intelligence corps. Sequoia led AIR’s $10 million first seed round, and Greenoaks led a $40 million second round that closed within weeks of it, Saban told TechCrunch. AIR currently has about 40 employees and plans to use the capital primarily for research hiring and expansion in the United States and Europe.

The product has two operationally demanding parts. Continuous vetting requires repeated analysis across a changing public component pool, while runtime enforcement requires integration with the agents customers actually deploy. AIR also expects AI labs and platform providers to add their own checks. Saban argues that enterprises will still buy an independent layer spanning multiple vendors.

Cross-vendor coverage could give an independent product a durable role, especially where companies run several agent platforms. Platform-native controls could also absorb part of AIR’s function and leave independent vendors competing on threat intelligence, policy consistency, and enforcement coverage. The TechCrunch report offers AIR’s position, without evidence yet on which layer customers will treat as authoritative.

AIR’s launch gives buyers a concrete standard to test: trust should attach to the current component and action, with enforcement applied before access reaches an enterprise system.

Watch for AIR’s next customer disclosures after September 2, 2026, specifically named production deployments, measured block rates, false-positive data, reinspection triggers, and proof that its runtime hook covers every path an agent can use.

The Signal is the public edge of a private practice. Sherpa points the same intelligence engine at one owner's business — competitors, suppliers, regulators, watched daily, graded and sourced. Work with a Sherpa →