In August 2025, the automated systems in DARPA's AI Cyber Challenge analysed more than 54m lines of code. Across the final competition, they found 54 of 63 synthetic vulnerabilities and 18 real vulnerabilities that had not been planted for the contest.

Those results did not show that autonomous systems had replaced security researchers or that every organisation could expect the same performance. They did show that vulnerability discovery and patch generation were becoming faster and more automated. DARPA said the competitors patched 43 synthetic vulnerabilities and supplied 11 patches for real ones.

The scarce resource may soon be the decision that follows a finding: whether the evidence is sound, which system can be changed, who carries the consequence and how the change can be reversed.

Faster Findings Create a Queue of Decisions

DARPA's account of the final competition is unusually useful because it separates the achievement from the hype. The systems worked against 63 synthetic challenges based on real-world software. The contest scored their ability to find and prove vulnerabilities, generate patches and pair the two accurately. Every team also found at least one real vulnerability.

This was a structured competition with known rules, substantial technical support and a defined code corpus. It was not an enterprise security operation dealing with incomplete asset records, disputed ownership and changes that may interrupt customers.

That difference is where the leadership problem begins. If finding and proposing fixes speeds up, the next queue contains judgements: Is this a real flaw? Is the patch safe? Which service owner can accept the risk of applying it? Can the change be tested and rolled back before the exposure is exploited?

“A human reviews everything” Is no longer practical when there's a flood of findings to be processed

“A human reviews everything” is not a durable answer when the inflow accelerates. Nor is it sustainable to let the discovery system make every change it recommends. Low-consequence, reversible work can be pre-authorised inside narrow boundaries. A production change with a wide blast radius still deserves fresh authority.

A Valid Token Can Carry an Invalid Action

The authority problem predates AI agents. Between 8 and 18 August 2025, an actor tracked as UNC6395 used compromised OAuth tokens associated with the Salesloft Drift application to access Salesforce customer instances and export data.

Google Threat Intelligence Group's account said the actor systematically queried Salesforce objects and searched the stolen data for credentials and secrets. Salesloft and Salesforce revoked the affected tokens and removed the Drift application from Salesforce's AppExchange while investigating the incident.

This was token theft, not an AI system drifting from its task. Its value as an example lies in the control gap. The tokens represented a legitimate integration and carried real permissions. Once compromised, those facts helped the attacker act; they did not make the action legitimate.

Identity answers which account, service or workload is present. Permission answers what it can actually reach

Identity answers which account, service or workload is present. Permission answers what it can actually reach. Neither, alone, answers whether the action still serves the purpose for which access was granted.

That distinction applies directly to agents. A workload may have a valid identity and a legitimate starting task, then encounter new data, choose another tool or attempt an export that the original authority did not cover.

AI Observability is Becoming part of the Authority Record

On 7 October, IBM announced AgentOps, which it described as an observability and governance layer for agents, alongside orchestration capabilities across its software portfolio.

This was a product announcement. It does not establish that observed agents are safe or that a dashboard can resolve questions of authority. It does show what enterprise buyers will increasingly be offered: records of agent activity, policy controls and monitoring around systems that can call tools and alter workflows.

The important record must connect more than an identity to an event. It should show the task approved, the data and tools permitted, the action attempted, the condition that allowed it, and the resulting change. Otherwise, telemetry proves that something moved without showing whether it was entitled to move.

Final Perspective

Faster discovery is valuable only if the organisation has decided what may happen next. For one vulnerability workflow, I'd want the security lead and service owner to show the exact class of action allowed before a person is available: opening a ticket, testing a patch in an isolated environment or making another narrow change that can be reversed without interrupting the service.

Production deployment is a different decision because a wrong patch can harm the service it is meant to protect. An empty chair at two in the morning does not reduce that consequence. If an automated system found a critical flaw tonight, which action could it safely take before anyone answered the phone?