By NHI Mgmt Group Editorial TeamPublished 2026-04-08Domain: Breaches & IncidentsSource: WitnessAI

TL;DR: Anthropic’s Project Glasswing shows a model finding zero-day vulnerabilities autonomously across production systems, with benchmark success jumping from 2 to 181 exploit completions and 29 register-control wins, according to WitnessAI’s analysis of Anthropic’s findings. The security problem is no longer discovery scarcity but governance for machine-speed exploitation, where runtime controls, AI visibility, and agent oversight become decisive.


At a glance

What this is: Anthropic’s Project Glasswing shows autonomous AI moving from code assistance into zero-day discovery and exploit development at machine speed.

Why it matters: IAM, NHI, and security governance teams now need runtime controls for AI interactions, because identity, tool access, and auditability all become operational risks when models can act autonomously.

By the numbers:

  • A 17-minute average window separates public AWS credential exposure from attacker access attempts, dropping to 9 minutes in some cases.

👉 Read WitnessAI’s analysis of Anthropic Project Glasswing and AI exploit discovery


Context

AI security is no longer limited to prompt abuse or model misuse. The harder problem is that modern models can discover, chain, and exploit software flaws across operating systems, browsers, and libraries faster than human teams can triage them, which turns identity, access, and governance into runtime issues rather than quarterly review topics.

For IAM and NHI programmes, this matters because autonomous model behaviour changes the trust model. If a model can select tools, chain actions, and complete exploit paths without human approval, then access review, least privilege, and audit logging have to account for machine-timed execution, not just human-requested access.


Key questions

Q: How should security teams govern AI systems that can act without human approval?

A: Security teams should govern autonomous AI the same way they govern other high-risk identities, but with runtime enforcement instead of periodic review. That means tightly scoping tools, data, and actions; logging every material step; and making revocation and containment available while the session is still active. Static policy alone does not control machine-paced execution.

Q: Why do autonomous AI systems create new identity governance risk?

A: Autonomous systems create identity risk because they can choose actions, select tools, and execute before a human can intervene. That breaks the assumption that access is stable long enough for review or correction. Once execution is self-directed, the real control point becomes the runtime boundary, not the quarterly certification cycle.

Q: What do security teams get wrong about AI exploit discovery?

A: Teams often assume exploit discovery remains a scarce human activity, but the article shows machine-speed discovery and chaining across real software surfaces. That changes how fast an exposed flaw can become a usable attack. The mistake is treating AI security as a future concern when the offensive capability is already operational.

Q: Which frameworks should organisations use for autonomous AI governance?

A: Use OWASP agentic and LLM guidance for application risk, NIST AI RMF for governance structure, and MITRE ATLAS for adversarial technique mapping. Then translate those frameworks into operational controls that restrict tool access, define approval boundaries, and produce auditable runtime evidence. Frameworks help classify the risk, but enforcement must happen in execution.


Technical breakdown

Autonomous exploit discovery and exploit chaining

Project Glasswing points to a model that can move from vulnerability discovery to working exploit construction without human steering. In technical terms, that means the model is not just generating code, it is reasoning across memory corruption patterns, control-flow constraints, and execution paths until it reaches a usable chain. The article also describes kernel escalation, browser-engine exploitation, and multi-packet ROP construction, which are all signs of end-to-end attack synthesis rather than isolated bug finding. That changes the attacker model from researcher-assisted to machine-orchestrated.

Practical implication: defenders need to treat exploit development as a machine-speed control problem, not a human-capability problem.

Why runtime governance matters for AI model access

The article ties AI capability to governance because models can now act across tools, codebases, and environments in ways that outstrip document-based policy. Runtime governance means controlling what the model can see, call, and persistently access while it is operating, not after the fact. This is different from static approval workflows because the security boundary moves with each interaction. In identity terms, the issue is not only authentication of the model or user, but authorisation of every action the model can trigger across systems.

Practical implication: teams should align model permissions, logging, and execution boundaries before agentic workflows are allowed into production.

AI security frameworks versus machine-scale attack surface

The article references OWASP, NIST AI RMF, MITRE ATLAS, and agentic application guidance because the attack surface spans application logic, orchestration, and underlying infrastructure. These frameworks help organise risk, but they do not remove the operational burden of visibility and enforcement. When a model can evaluate targets at machine speed, the gap between policy and enforcement becomes the real failure point. The security architecture must therefore combine discovery, classification, and monitoring across models, tools, and data paths.

Practical implication: map current AI deployments to named frameworks, then test whether enforcement exists at the point of execution.


Threat narrative

Attacker objective: The objective is to use autonomous AI to turn software flaws into reliable exploitation paths faster than human defenders can discover or patch them.

  1. Entry occurs when an autonomous model is given access to production code, test paths, or connected tools that let it inspect real software surfaces without human review.
  2. Escalation follows when the model chains discovered weaknesses into proof-of-concept exploits, including multi-step kernel and browser attack paths that require no manual prompt-by-prompt steering.
  3. Impact is achieved when the model converts discovery into weaponised access, including root-level execution, unauthenticated compromise, or rapid exploitation before defenders can react.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Autonomous vulnerability discovery collapses the scarcity assumption behind defensive security. For decades, security programmes assumed exploitable flaws were expensive to find and therefore reasonably scarce. This article shows that a model can independently locate and weaponise bugs across major software surfaces, which makes discovery cost a structural variable rather than a specialist skill. The implication is that defenders can no longer rely on attacker friction as a control.

Runtime authorisation for AI tools is now an identity problem, not just an AI problem. When a model can select targets, call tools, and continue execution without human approval, the control plane becomes part of the identity plane. That means the access decision is no longer limited to authentication or API scope at provisioning time. Practitioners should read this through OWASP-NHI, ZT-NIST-207, and NIST-CSF because the risk is permissioned execution at machine pace.

Access review processes were designed for access that persists long enough to be reviewed, and that assumption fails under autonomous execution. The article’s own example of no-human-in-the-loop exploit chaining shows how privilege can be created, used, and exhausted inside one session. That assumption collapse is what makes traditional recertification blind to the real risk window. The implication is that governance must be reconsidered around execution events, not periodic review artefacts.

Machine-speed exploitation changes the governance threshold for AI deployment. The point is not that every AI model is inherently dangerous, but that general capability gains can unexpectedly create offensive security behaviours. That means AI governance cannot stop at acceptable-use policy or quarterly risk review. Practitioners should assume that any model touching code, credentials, or execution paths needs runtime controls and auditability.

Identity blast radius: Once a model can traverse code, tools, and infrastructure autonomously, the relevant security question becomes how far one execution path can propagate before detection. That is a broader concern than point-in-time vulnerability scanning. The practitioner conclusion is that identity scope, tool scope, and data scope must be constrained together, or the blast radius becomes unbounded.

From our research:

  • 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% having only partial visibility, according to The State of Non-Human Identity Security.
  • Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities, which shows the confidence gap is already structural.
  • Forward-looking programmes should pair that visibility gap with Ultimate Guide to NHIs , Key Challenges and Risks to build controls for discovery, scope, and lifecycle enforcement.

What this signals

Identity blast radius: the practical question for security teams is no longer whether AI can be used, but how much authority any single model interaction can accumulate before it is contained. When a system can chain tool calls and code paths autonomously, the blast radius expands faster than human review cycles can shrink it, which is why runtime governance has to sit alongside identity governance.

The organisational signal is clear. Discovery, classification, and enforcement now need to cover models, agents, and the services they can reach, not just the user who initiated them. Teams that still separate AI policy from IAM will find that approval workflows do not control execution paths.

AI programmes should be measured by what they can stop at the point of action. If a model can inspect code, call tools, and produce effects without producing usable audit artefacts in real time, the governance design is incomplete, regardless of how strong the written policy appears on paper.


For practitioners

  • Inventory all AI-connected execution paths Map where models can read code, invoke tools, access repositories, or trigger downstream actions. Include IDE assistants, agent frameworks, CI jobs, and API-integrated workflows so you can see where execution is already crossing identity boundaries.
  • Separate model visibility from model authority Do not let read access, write access, and action authority move together by default. Assign the smallest practical scope for code, secrets, and runtime tools, and require explicit approval for anything that can alter production assets.
  • Test runtime governance against autonomous behaviour Simulate a model that chains actions without waiting for a human checkpoint, then verify whether logging, containment, and revocation still work. If controls only function after the session ends, they are not controlling the actual risk.
  • Anchor AI controls to named frameworks Map current deployments to OWASP LLM and agentic application guidance, NIST AI RMF, and MITRE ATLAS so your team can classify tool misuse, unsafe autonomy, and governance gaps consistently. Use the framework mapping to drive control ownership, not as documentation only.
  • Extend identity governance to agentic workflows Treat agents that can call tools and move through tasks without human review as governance subjects, not just application features. Define who approves their scope, who reviews their actions, and how scope drift is detected before it becomes an incident.

Key takeaways

  • Autonomous AI can compress vulnerability discovery and exploit development into a machine-speed workflow that traditional security assumptions do not model well.
  • The evidence in this article shows a step-change in capability, not an incremental improvement, which means the exposure window for software flaws is shrinking fast.
  • Security teams need runtime governance, scoped authority, and execution-level auditability before autonomous AI is allowed to touch code, tools, or production data.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10AGENTIC-03The article centers on autonomous tool use and exploit chaining.
NIST AI RMFAI governance and accountability are central to the capability shift.
OWASP Non-Human Identity Top 10NHI-03The model behaves like a non-human identity with tool authority.

Establish governance, measurement, and accountability for AI systems that can act independently.


Key terms

  • Autonomous AI Identity: An autonomous AI identity is a software actor that can choose actions, select tools, and execute without a human approving each step. In practice, it behaves like a non-human identity with decision authority, so governance must cover runtime scope, auditability, and revocation, not just login or API authentication.
  • Runtime Governance: Runtime governance is the control of what an AI system can do while it is operating, not after the fact. It covers permissions, approvals, logging, and containment at the moment actions occur, which is essential when model behaviour can change during a session and produce real-world effects immediately.
  • Identity Blast Radius: Identity blast radius is the amount of damage one identity can cause before it is stopped or contained. For autonomous systems, the concept expands beyond account scope to include tool access, code reach, and data movement, because a single execution path can cascade across multiple systems very quickly.
  • Assumption Collapse: Assumption collapse is the failure of a governance premise that used to make sense for slower, human-paced identity behaviour. In autonomous contexts, it describes controls that assume access will persist long enough to review, approve, or certify when the actor can create and consume access inside one session.

Deepen your knowledge

Autonomous AI governance and runtime control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agentic systems or machine-speed execution, it is worth exploring.

This post draws on content published by WitnessAI: Anthropic’s Project Glasswing and the emerging AI security challenge. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-04-08.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org