Air Security raised $50 million and launched a Context Firewall to govern AI agent skills, plugins, and MCP servers, addressing supply chain and
AI agent security startup Air Security has recently made its official debut and announced that it has raised a total of $50 million in funding, while also launching an AI agent firewall product. The product is positioned as a “Context Firewall” for AI agents and primarily inspects the add-ons used by AI agents, including agent skills, plugins, and Model Context Protocol (MCP) servers.
According to the public materials, Air’s core value lies not only in blocking risky components, but also in identifying “which agents and which workflows are using which components,” and revoking their use within the organization once a component is confirmed to be problematic. This means the design approach is not simply about blocking; it incorporates AI agent dependencies into the governance perspective.
Yair Saban, cofounder and CEO of Air, told SecurityWeek that as AI agents independently use different tools and external services, organizations may have difficulty tracking which resources each agent actually depends on. If a component contains malicious content, has vulnerabilities, or is unapproved, it may also be difficult to determine which agents and workflows are using it.
On the product side, Air integrated Anthropic Compliance API in June this year, bringing usage, governance, and audit data for Claude within organizations into its existing management scope. In August and September, it was also listed on AWS Marketplace and Google Cloud Marketplace, allowing enterprises to adopt Air through existing cloud procurement processes. This shows that its market strategy targets both technical governance and enterprise procurement entry points.
In addition, OWASP cited Air’s research and noted that more than 10% of public agent skills reference untrusted external instruction sources, highlighting the supply chain risks posed by third-party resources to AI agent skills.
The technical focus of this news is not a traditional single vulnerability, but the “context dependency” problem in the AI agent ecosystem. When agents can proactively call tools, read external services, and connect skills and MCP servers, the risk boundary no longer exists only in the model itself; it spreads across the entire add-on chain.
From the name and public descriptions, the key idea behind a Context Firewall is to inspect and control the context sources an agent encounters while executing tasks. This type of protection is especially suitable for traceability questions such as “what did the agent call,” “which plugins did it use,” and “which MCP servers did it depend on,” because AI agent security incidents are often not caused by a single point of failure, but by multiple third-party components jointly forming the attack surface.
The research result cited by OWASP is especially noteworthy. If more than 10% of public agent skills reference untrusted external instruction sources, then skills themselves may become an entry point for supply chain contamination. The essence of this risk is that, during execution, the agent treats external content as usable context; once the source is untrusted, it may bring incorrect instructions, malicious instructions, or unauthorized content into the decision-making process.
At the governance level, Air’s emphasis on tracing the agents and workflows that use problematic components reflects the fact that AI agent protection has entered an era of “correlation analysis.” Enterprises must not only know that a component is risky, but also know which tasks, departments, and automation flows have been affected; otherwise, even if a problem is detected, isolation and revocation cannot be completed quickly.
From an enterprise deployment perspective, integrating Anthropic Compliance API is also significant. It means governance data, usage data, and audit data can be folded into existing management scopes, allowing AI agent activity to move beyond black-box operations and into compliance and audit processes. For organizations adopting Claude-related capabilities, this kind of integration helps elevate AI governance from single-tool control to platform-level management.
The first impact of this event falls on enterprises that have already deployed, or are preparing to deploy, AI agents. As long as agents automatically call plugins, skills, or MCP servers, problems such as incomplete component inventories, unclear authorization sources, and difficult-to-trace workflows will arise. The more highly automated the scenario, the easier it becomes for the risk surface to expand unnoticed.
Second, the impact also includes cloud-native and multicloud procurement workflows. Air’s availability on AWS Marketplace and Google Cloud Marketplace means its product can be directly embedded into existing enterprise procurement and deployment paths. This will accelerate adoption, but it also means AI agent protection will become part of cloud security governance more quickly, rather than remaining an experimental solution for only a few large organizations.
Third, for security teams, the most immediate impact is an increase in audit burden. When the components an agent depends on span internal assets, external services, and third-party skill providers, traditional asset inventory and access management methods may not fully cover the environment. Security teams need to expand from “hosts, accounts, APIs” to four layers: “agents, skills, context, workflows.”
Fourth, from a supply chain governance perspective, the research cited by OWASP is a warning. If public agent skills already include untrusted external instruction sources, it indicates that the market for skills and components is still immature. Enterprises must establish review standards before adoption, or they may easily import third-party risk directly into internal automation environments.
To address this type of AI agent supply chain risk, the first priority is to establish a component allowlist and approval process. Any agent skills, plugins, MCP servers, and external instruction sources should first undergo source verification, usage review, and risk classification before being allowed into production.
Second, enterprises should make “visibility into the relationship between agents and components” a security requirement. Security teams need to know which resources each agent actually invokes and which workflows are consuming which skills so they can quickly determine impact scope and revoke access when vulnerabilities, malicious content, or unapproved components appear.
Third, audit data and governance data should be retained together and included in routine inspections. Since Air has integrated usage, governance, and audit data into its management scope, enterprises should follow the same approach and preserve agent operation logs, component change logs, and authorization change logs to support post-incident investigation and compliance needs.
Fourth, stricter trust evaluation should be applied to public agent skills and third-party context sources. OWASP pointed out that more than 10% of public agent skills reference untrusted external instruction sources, which means “seems usable” does not equal “trustworthy.” Any external content that can affect agent decisions should first be verified and constrained by least privilege controls.
Fifth, if the organization has already deployed Claude or other AI services, it should review whether existing cloud procurement and governance processes adequately cover AI agent add-ons. Existing cloud governance often focuses on accounts, APIs, and infrastructure, but the risks of AI agents now extend to higher-level context and skills, so control points must be adjusted accordingly.
Overall, Air Security’s debut shows that AI agent security is moving from model protection into the stage of supply chain and context governance. As agents become capable of autonomously calling tools and external services, the protection focus must also evolve from “preventing model abuse” to “preventing the entire agent ecosystem from being contaminated.”