When your AI agents start finding vulnerabilities at enterprise scale, the question isn't whether they work. It's who governs them.
Last week, OpenAI launched Codex Security. In its first public run, the system scanned 1.2 million commits across major open-source projects and found 792 critical and 10,561 high-severity vulnerabilities, including 14 CVEs affecting OpenSSH, GnuTLS, Chromium, and GnuPG.
The same week, Anthropic published results from a Mozilla partnership: Claude identified 22 Firefox vulnerabilities — 14 of them high-severity, including a CVSS 9.8 JIT miscompilation flaw — for approximately $4,000 in API credits. That's roughly 20% of Firefox's entire 2025 high-severity patch count, found by one AI session.
AI security agents have arrived. They work. They work shockingly well.
And nobody is governing them.
The Scale Problem
When a human penetration tester audits a codebase, they produce a report. One person, one assessment, one scope. The tester has credentials, access boundaries, and a statement of work defining exactly what they can touch.
AI security agents don't operate at human scale. Codex Security scanned 1.2 million commits. Not one repository — millions of commits across hundreds of projects. In hours, not months.
When enterprises deploy these agents internally — scanning their own repositories, APIs, infrastructure, and configurations — they'll be running hundreds or thousands of concurrent security scans. Each agent has access to source code. Each agent can read configuration files. Each agent can access API documentation, internal architecture diagrams, and credentials stored in environment variables.
A security agent with broad code access is, by definition, one of the most privileged agents in any organization.
And privilege without governance is exactly how breaches happen.
The Irony of AI Security
Here's the paradox: the agents designed to find vulnerabilities are themselves a new attack surface.
Consider what a security scanning agent needs to function:
- Read access to source code — including proprietary business logic
- Access to build configurations — which contain deployment secrets
- Access to dependency trees — which map the entire supply chain
- Access to test environments — which often mirror production data
- Access to vulnerability databases — which reveal known weaknesses
Now imagine that agent gets prompt-injected. Or that its MCP connection is compromised. Or that a malicious actor gains access to the agent's output — a neatly organized inventory of every vulnerability in your codebase, ranked by severity, with exploitation paths documented.
You've essentially created an automated red team that can be turned against you.
This isn't theoretical. Four confirmed MCP attacks have already occurred in production environments, including ContextCrush — a supply chain attack on the Context7 MCP Server (50,000 GitHub stars, 8 million npm downloads) that demonstrated .env exfiltration and file deletion through injected instructions. If a development-focused MCP server can be compromised, a security-focused one operating with higher privileges presents an even more attractive target.
Anthropic Found Firefox Bugs for $4K. What Does Mass Deployment Look Like?
The economics are staggering. Anthropic's Claude found 22 Firefox vulnerabilities for $4,000 in API credits. Traditional bug bounty programs pay $5,000 to $50,000 per vulnerability. Human penetration testing engagements cost $50,000 to $500,000 for a single assessment.
AI security scanning is 100x cheaper than human alternatives. This means every enterprise will deploy it. Not because it's optional — because the economics make it irrational not to.
Gartner projects that 40% of enterprise applications will embed AI agents by the end of 2026. When security scanning agents become a standard capability — like antivirus was in the 2000s — the question shifts from "should we deploy them?" to "how do we govern hundreds of security agents scanning everything, continuously?"
Who decides which repositories they can access? Who monitors their output to ensure vulnerability reports don't leak? Who ensures they're not being manipulated into generating false negatives — telling you a critical flaw doesn't exist when it does?
Who watches the watchers?
The Meta-Governance Problem
Enterprises are already struggling to govern their first-generation AI agents — the ones doing customer support, data analysis, and workflow automation. According to Everest Group, only 7% have agentic-specific governance policies in place.
Security agents add a new layer of complexity:
1. They require the highest privileges. A customer service agent needs access to tickets. A security agent needs access to everything it's scanning. The blast radius of a compromised security agent is orders of magnitude larger than a compromised support agent.
2. Their output is inherently sensitive. A vulnerability report is simultaneously the most valuable document for defenders and attackers. Governance must ensure these reports follow strict access controls — but today, most AI agent outputs are logged in shared observability platforms with broad team access.
3. They operate continuously. Human pentesters work on engagements with defined start and end dates. AI security agents run continuously. That's continuous access to sensitive code, continuous generation of sensitive output, and continuous exposure to supply chain and prompt injection risks.
4. They interact with other agents. In modern multi-agent architectures, a security scanning agent might hand findings to a remediation agent, which hands patches to a deployment agent. If the scanning agent is compromised, the entire chain executes on malicious input.
What Governed Security Agents Look Like
Governing AI security agents requires the same framework as governing any AI workforce — with higher stakes and stricter controls:
Identity and Access. Every security agent must have its own identity — not shared API keys. Scoped permissions tied to specific repositories, specific scan types, specific time windows. Microsoft's Entra Agent ID and AWS's AgentCore Policy provide single-platform foundations, but enterprises running security agents across multiple platforms need cross-platform identity governance.
Output Classification. Vulnerability reports should be automatically classified by sensitivity and routed through access controls. A critical CVE in a production authentication system should not be visible to the same audience as a low-severity formatting bug.
Behavioral Monitoring. If a security agent suddenly starts scanning repositories outside its assigned scope, or if its output patterns change (more "no vulnerabilities found" when there should be findings), that's a governance alert. Intent drift in security agents isn't just wasteful — it's potentially dangerous.
Supply Chain Verification. The tools and MCP servers that security agents connect to must be verified and governed. ContextCrush proved that MCP server supply chains are attackable. A security agent using a compromised MCP server is worse than having no security agent at all.
Human-in-the-Loop for Critical Actions. Finding vulnerabilities is one thing. Auto-patching them is another. Any governance framework for security agents must define clear escalation paths: what requires human review, what can be automated, and what the override mechanisms are.
The Bigger Picture
OpenAI and Anthropic launching security agents isn't just a product announcement. It's the beginning of a new agent category that will exist in every enterprise within 18 months.
These agents will find real vulnerabilities. They'll save real money. They'll make organizations genuinely more secure.
They'll also be among the most privileged, most sensitive, and most attack-worthy agents in any enterprise's portfolio. And they'll need governance that matches their risk profile.
The irony of deploying AI agents to find security vulnerabilities — without governing those agents securely — shouldn't be lost on anyone. But it will be, unless the industry builds governance into the deployment from day one.
Because the question was never whether AI could find vulnerabilities. The question is whether we can govern the AI that does.
iEnable is building the AI Company OS — unified governance for your entire AI workforce, from customer service agents to security scanners. Because every agent needs management. Especially the ones with the keys.
Need cross-platform AI agent governance?
iEnable gives you visibility and control over your entire AI workforce — regardless of platform. No blind spots. No ecosystem lock-in.
Learn More About iEnable →Related reading: