AI Agent Add-Ons Need the Equivalent of Signed Drivers
Enterprise AI teams are moving from asking whether an agent is safe to asking a more urgent question: what did the agent install, connect to, or learn from before it acted?
That shift matters because the useful agent is rarely a sealed application. It is a system that reaches outward. It calls an MCP server, loads a skill, retrieves a document, uses a connector, follows instructions in a web page, and acts in systems that contain real company data. The agent is not just software. It is a supply chain in motion.
This week, agent security startup AIR emerged publicly with $50 million in seed financing focused on that supply chain. Its stated premise is straightforward: agent skills, plugins, MCP servers, subagents, websites and internal data can all become inputs to an agent's context, and each input can change what the agent does. That is not a niche security problem. It is the operating model enterprises are rapidly adopting.
The most useful analogy is not another AI chatbot. It is the signed driver.
Why an agent extension is more like a driver than an app
A traditional application is usually reviewed as a distinct piece of software. An agent extension behaves differently. It can expose tools, inject instructions, request credentials, direct retrieval, and shape actions downstream. A seemingly harmless connector can turn into a path to sensitive data or a vehicle for a prompt injection attack.
AIR CEO Yair Saban made the comparison clearly in reporting on the launch: modern operating systems expect drivers to be signed because they load code into a sensitive part of the machine. Agent skills and plugins can alter a similarly sensitive part of an agent: its working context and permitted actions. Yet enterprises often install them with far less evidence of provenance, scope, or change control.
That gap is bigger than a vulnerability scan can solve. A package can be free of known malware and still be unsafe for a particular agent. A skill might be legitimate but ask for more tools than its job requires. An MCP server might be trustworthy today and pull different instructions tomorrow. A connector might have a valid business purpose but be inappropriate for an agent handling contracts, customer records, or finance workflows.
The governing question is therefore not simply, "Is this add-on malicious?" It is, "Should this agent be allowed to consume this component, with this identity, this data, and this authority, at this point in time?"
The hidden problem: procurement is happening inside workflows
Most enterprise security programs already have a process for approving SaaS vendors. They may have software composition analysis for developer dependencies. But agent add-ons are often acquired in a much less visible way.
An employee creates a workflow. The workflow needs a new capability. The agent builder selects an MCP server or skill from a catalogue, a Git repository, a marketplace, or a colleague's recommendation. A permission prompt appears. Work continues.
That is procurement, integration, and production deployment compressed into a few clicks.
It also produces Shadow AI in a new form. The issue is no longer only employees pasting sensitive data into an unapproved model. It is unapproved agent components being granted access to enterprise systems, often by well-intentioned teams trying to move faster. The security team cannot govern what it cannot discover, and it cannot make good decisions from a spreadsheet that is stale the day after it is created.
Build an agent add-on trust process, not a one-time review
The answer is not to ban every connector. That would push adoption out of sight. The answer is to make the safe path faster than the invisible path.
Start with four practical controls.
1. Create an AI component inventory
Track agents, skills, MCP servers, plugins, connectors, models, data sources, owners, and the systems each component can reach. Include both sanctioned and discovered components. An inventory that lists only approved tools is a policy register, not a risk register.
Aona's [AI-BOM framework](/blog/ai-bom-shadow-ai-enterprise-security-inventory) is a useful starting point: treat the agent's dependencies and integrations as first-class governance objects, not implementation detail.
2. Require provenance and purpose before connection
For every external component, capture who maintains it, where it is sourced, what it does, what data it can access, what tools it can invoke, and the business workflow it supports. This should be proportionate. A read-only knowledge search is not the same as a connector that can send emails, modify a CRM record, or trigger a payment workflow.
The key is evidence. "It is popular" and "the team needed it" are not risk decisions.
3. Bind authority to the task, then let it expire
An agent should receive the minimum authority needed for a specific task, not a standing set of broad permissions. Use distinct identities where possible. Scope tools tightly. Set time limits. Require human approval for high-impact actions.
That approach builds on a principle we covered in [AI agent permissions](/blog/ai-agent-expiring-permissions-enterprise-governance): revocation must be designed in before an incident, not improvised after one. It also stops a compromised or changed add-on from inheriting more power than its work warrants.
4. Continuously verify changes and runtime behavior
Signing or reviewing a component once is not enough. Agent add-ons change. Their dependencies change. Their instructions and external endpoints can change. Monitor for configuration drift, new permission requests, altered tool calls, unexpected data access, and actions outside the agent's approved purpose.
This is where governance becomes operational. Alerts need an owner and a decision path: allow, restrict, quarantine, or investigate. Observability without the ability to intervene is a better incident report, not a control.
What CISOs should ask this quarter
A useful executive review is short and specific:
- Which AI agents and add-ons are currently connected to our systems?
- Which of those components were discovered rather than formally approved?
- Can we identify the data, tools, identities, and owners associated with each one?
- What happens when a component changes after approval?
- Which actions require a person to approve them before they execute?
If the answers require manual archaeology across multiple teams, the enterprise has already reached the point where agent adoption is outpacing governance.
The AIR launch is a timely signal, not because one new vendor changes the market, but because it names a real architectural change. The attack surface is now the chain of context, tools, and components an agent relies on. Security controls designed for static applications will miss that movement.
Enterprises do not need to slow down their AI programs. They need to treat an agent's add-ons as trusted computing components: discover them, verify them, constrain them, and keep verifying them after deployment.
If you are trying to map Shadow AI and the agent connections already operating across your environment, [talk to Aona](/contact-us?utm_source=blog&utm_medium=organic&utm_campaign=agent-add-on-governance). We help security teams turn AI discovery into policy, evidence, and action.
