Summary
AI security startup AIR is emerging from stealth with $50 million raised across two seed rounds to help companies discover internal AI agents, continuously vet the tools they use, and block interactions that fail security requirements. The funding comes as agent skills, plug-ins, MCP servers, and other add-ons begin to form a new software supply chain.
AI agents are creating a new software supply chain
Enterprise AI adoption is moving beyond chat interfaces and isolated productivity tools. Companies are increasingly experimenting with agents that can call software, browse the internet, execute workflows, and connect to internal systems. Those capabilities depend on a growing collection of skills, plug-ins, MCP servers, connectors, and other add-ons.
Together, these components are beginning to look like a new software supply chain. The security challenge is not limited to whether an underlying model produces a reliable answer. Companies also need to know which agents are operating in their environments, what tools those agents can invoke, where the tools came from, and whether their behavior remains within an approved risk boundary.
TechCrunch reported that AI security startup AIR is coming out of stealth with $50 million raised across two seed rounds to build a product around that problem. The company’s premise is that enterprises will need ongoing visibility into the components used by agents, rather than relying only on an initial approval when an agent is first deployed.
AIR’s approach: discovery, assessment, and blocking
AIR was founded by Yair Saban, its chief executive, and Niv Hoffman, its chief technology officer. Both are veterans of Israel’s Unit 8200, where they worked in offensive cybersecurity, according to the company’s public description.
AIR says its platform can discover agents running inside a company and continuously vet the skills, tools, and other components those agents use. If a component does not meet an organization’s security criteria, the platform can block the agent from interacting with the relevant software or external source.
That approach shifts governance from a one-time onboarding decision toward runtime oversight. An enterprise might approve an agent at the start of a project, but the agent’s risk profile can change as new skills are added, third-party tools are updated, or the agent is given access to additional systems. Continuous assessment is intended to address that moving target.
AIR also offers a marketplace of vetted skills and add-ons for AI agents. A curated marketplace could give enterprises a more centralized way to identify and manage components. It does not, however, eliminate the need for an organization to define its own review criteria. “Vetted” must be tied to questions such as what permissions a component requires, what data it can access, how updates are reviewed, and who is responsible if its behavior changes.
Why traditional application controls may not be enough
AIR has compared the governance of agent tools with the evolution of security practices for software drivers. In earlier computing environments, drivers did not necessarily carry a signature that identified the publisher. Over time, signatures and other provenance mechanisms became part of the process for establishing trust in installed software.
The comparison highlights several controls that the agent ecosystem may need: component identity, publisher information, permission scope, version tracking, change history, and an audit trail of activity. But agents introduce additional complexity because they can select and combine tools dynamically in response to a task.
A plug-in might allow an agent to read files, call a database, send a network request, or invoke another application. The agent may then combine that plug-in with several other capabilities in a single workflow. Knowing who published a component is important, but it does not by itself explain how the component will behave in a particular context or what data the surrounding agent can reach.
As a result, enterprise governance is likely to involve several layers. Organizations need an inventory of agents, a map of the tools and data each agent can access, information about the origin and updates of those tools, and records of actions taken. They also need a way to interrupt behavior when an agent deviates from policy. These controls address authorization and accountability as much as they address conventional malware detection.
The implications for financial and institutional systems
AI agents are being evaluated for uses in customer support, finance operations, payment workflows, compliance processes, and risk management. In these settings, the relevant security boundary is not just the model or the application that hosts it. A connector, plug-in, MCP server, or skill may become an additional route into internal data or operational systems.
For institutional wallets, digital-asset custody platforms, and payment infrastructure, the stakes can be particularly high. An agent that can view information from a key-management environment, prepare transaction data, access customer records, or trigger an action in an external system should operate within clearly separated permissions and an auditable workflow.
An agent-governance product may help provide visibility and enforcement, but it cannot replace broader controls. Those controls can include least-privilege access, segregation of duties, human review for sensitive actions, secure key isolation, detailed logging, and internal compliance procedures. Where an action is difficult to reverse, organizations are unlikely to be able to rely solely on a component’s security label or default configuration.
Continuous monitoring also has a supplier-management dimension. Enterprises may need to understand how often a third-party skill changes, whether its permissions expand, whether data is routed to an external service, and how quickly the component can be disabled if a new risk is identified. For organizations operating across multiple wallets, custodians, payment networks, or internal platforms, component-level visibility may become part of a broader audit and risk-management framework.
What the financing says about the market
The company told TechCrunch that the two financing rounds closed within weeks of one another. The first round raised $10 million and was led by Sequoia, while the second raised $40 million and was led by Greenoaks. Swish, Netz, and a group of individual investors also participated, according to the report.
The financing does not establish that the industry’s agent-governance problems have been solved. It does show that a segment of the security market is forming around a specific concern: the safety of an AI agent depends not only on the model, but also on the external capabilities the agent can discover, install, and invoke.
That concern becomes more consequential as agents move from internal experiments into business-critical workflows. A conventional automation script may have a fixed set of dependencies and a relatively predictable execution path. An agent can have a broader operating surface, respond to changing instructions, and interact with tools whose behavior may evolve over time. Treating the agent and its capabilities as a continuously changing software asset may therefore be more appropriate than treating it as a one-time configuration.
The next phase of competition in this market is likely to focus on the completeness of agent discovery, the verifiability of component reviews, the precision of permission controls, and the operational effects of blocking unsafe behavior. For enterprises, knowing which agents exist is only the starting point. The more consequential questions are what those agents can use, on whose behalf they can act, what information they can reach, and whether the organization can see and stop problematic activity in time.
Source: link