AI Agents Are Finding Zero-Days Faster Than Security Teams Can Govern Them

A security startup just reported 21 previously unknown vulnerabilities in FFmpeg, one of the most widely embedded media libraries on the internet.

The uncomfortable part was not only the number of bugs.

It was how they were found.

An autonomous AI security agent scanned roughly 1.5 million lines of C, produced reproducible proof-of-concept inputs, and surfaced confirmed zero-days for about $1,000 of compute. In the same week, Google patched a record 429 Chrome security bugs after changing its bounty program to handle a flood of AI-generated reports.

This is not a small productivity improvement. It is a new operating tempo for vulnerability discovery.

For CISOs, the question is no longer whether AI can help find security issues. It clearly can. The harder question is whether the organization has governance that can keep up when AI increases the volume, speed, and ambiguity of security findings.

The zero-day bottleneck is moving

For years, the bottleneck in vulnerability management was discovery.

Finding a meaningful bug took scarce human expertise, time, and deep familiarity with a codebase. That constraint shaped how security teams thought about risk. You could prioritize based on known CVEs, vendor advisories, exploit activity, and asset exposure because the stream of new findings was noisy but still somewhat bounded.

AI changes that constraint.

If an autonomous agent can scan a large open-source project and produce dozens of plausible findings quickly, the limiting factor shifts from discovery to validation, prioritization, ownership, disclosure, and remediation.

That sounds operational. It is actually governance.

Who is allowed to run autonomous vulnerability research against internal code? What systems can they point it at? What happens when the agent finds a bug in a third-party dependency, a customer-facing workflow, or a regulated system? Who reviews the proof of concept before it is stored, shared, or escalated? How do you prevent sensitive code, secrets, or exploit details from being pasted into unmanaged AI tools during the process?

Most companies do not have crisp answers yet.

AI-generated security findings create a trust problem

AI does not just find issues. It creates work.

Some findings will be real. Some will be duplicates. Some will be low-impact. Some will be subtly wrong. Some will include proof-of-concept artifacts that create risk if mishandled. Some will look urgent because the agent writes with confidence, even when the exploitability is unclear.

That creates a new trust problem inside the security team.

If every engineer, red teamer, vendor, and external researcher can use AI to generate security reports at scale, security operations need a way to separate signal from automation noise without burning out the people responsible for review.

This is where many AI governance programs are still too narrow. They focus on whether employees can use ChatGPT, Claude, Gemini, or Copilot. That matters, but it is not enough.

The bigger issue is that AI is becoming part of the security workflow itself. It is running tests, generating reports, writing proof-of-concept code, summarizing vulnerabilities, suggesting fixes, and sometimes touching sensitive source code or production context.

That workflow needs visibility.

Shadow AI now includes shadow security tooling

Security teams often talk about shadow AI as a business-user problem: employees paste customer data into unapproved tools, marketing teams use AI apps, analysts upload spreadsheets, and so on.

But the same pattern is emerging inside technical teams.

A developer uses an agent to audit a repository. A security analyst uses a model to summarize suspicious code. A red teamer asks an AI tool to mutate exploit payloads. An engineer uploads logs to speed up root-cause analysis. A contractor uses their preferred AI assistant to review a dependency issue.

None of these behaviors are automatically malicious. In fact, many are useful.

But if they happen outside approved workflows, they create exactly the kind of blind spot that AI governance is supposed to reduce.

The risk is not simply data leakage. It is unmanaged authority:

• AI tools receiving source code, credentials, logs, or architecture details
• Agents generating exploit material without clear handling rules
• Findings entering ticket queues without provenance or confidence scoring
• Teams acting on AI-generated recommendations without review
• Sensitive remediation context being stored in personal AI accounts

This is why the FFmpeg example matters beyond open-source security. It shows what happens when vulnerability discovery becomes cheap and autonomous. The same pattern will appear in enterprise environments, but with private code, internal systems, and regulated data attached.

Policies will not keep up with agent speed

A PDF policy saying "do not upload sensitive data to AI tools" will not manage this problem.

Security teams need controls that operate where the work happens.

That means knowing which AI tools are being used, which identities are accessing them, what types of data are moving through them, and which workflows involve code, logs, tickets, vulnerabilities, or customer context.

It also means creating paved paths rather than blanket bans.

If employees believe approved tooling is slower than the AI assistant they already use, they will route around the policy. The answer is not to block every experiment. It is to provide safe, monitored ways to use AI for security work, with clear boundaries around data, actions, retention, and review.

For autonomous security agents specifically, enterprises should define:

• Approved targets: what codebases, systems, and environments agents can test
• Data boundaries: what source code, logs, secrets, and customer data can be shared
• Human review: who validates findings before escalation or remediation
• Artifact handling: how proof-of-concept code and exploit inputs are stored
• Disclosure rules: when findings involve third-party software or open source
• Audit trails: which agent ran, under whose authority, against what asset, and with what output

Without that structure, AI-powered security work becomes another form of shadow AI.

The CISO question changes

The old question was: "Are our teams using AI tools?"

The better question is: "Which AI-driven workflows now influence security decisions, code changes, vulnerability handling, or production risk?"

That is the level where governance has to operate.

AI agents finding 21 zero-days in a major library is impressive. It is also a warning. The enterprise security system around AI has to mature as quickly as the tools themselves.

Otherwise the next bottleneck will not be finding vulnerabilities.

It will be knowing which AI-generated findings to trust, which AI workflows touched sensitive data, and which risks your organization accidentally created while trying to move faster.

Aona helps teams close that gap by giving security leaders visibility into real AI usage, policy-to-behavior drift, and the workflows where AI starts touching sensitive data, code, and business decisions.

If your AI governance program still treats this as a tool access problem, it is time to widen the lens.