AI model findings expose why exposure management now exceeds CVEs

At a glance

What this is: This is an independent analysis of how AI-assisted vulnerability discovery changes the exposure conversation, with the key finding that CVE-centric programs miss identity, trust, and AI integration risks that attackers can use first.

Why it matters: It matters because IAM, PAM, NHI, and AI governance teams need to align remediation, privilege reduction, and exposure management around real attack paths rather than assuming vulnerability scanning captures the full risk picture.

By the numbers:

• Only 1% of 2025 CVEs were exploited in the wild.
• Gartner projected over one million CVEs by 2030.

👉 Read XM Cyber's analysis of AI-assisted vulnerability discovery and exposure management

Context

AI model-driven vulnerability discovery is accelerating the gap between what security teams can find and what attackers can actually exploit. In this case, the primary governance issue is not whether the model found flaws, but whether organisations can prioritise exposures across code, identity, and AI-enabled integrations before those paths are used in production.

For identity and access teams, the story matters because the article repeatedly moves beyond CVEs into misconfigured credentials, over-privileged AI systems, and trust-chain compromise. That combination is where NHI governance, PAM, and agentic AI controls intersect with traditional exposure management, and it is where many programmes still have weak visibility.

The starting position described here is becoming typical for medium and large organisations: strong on scanning, weaker on exploitation context, and weakest where identity and AI permissions converge.

Key questions

Q: What breaks when AI and identity controls are not aligned in exposure management?

A: When AI permissions, service identities, and exposure workflows are managed separately, organisations miss the paths attackers actually use. A flaw may be visible in a scan, but the real risk sits in whether a token can reach the system, whether an AI tool can write data, and whether the change can be reversed quickly. That gap turns remediation into theatre.

Q: Why do over-privileged AI integrations increase enterprise exposure risk?

A: Because access rights determine what an AI system can change, read, or trigger after authentication. If a model, connector, or agent has broader permissions than its task requires, it can become the easiest route to sensitive systems even when the underlying software is not vulnerable. Governance has to cover the identity of the system, not just its code.

Q: What should teams measure to know whether exposure management is working?

A: Track time to containment, secret revocation latency, and the percentage of high-risk systems covered by explicit ownership. If findings regularly sit between discovery and action, the programme is failing where AI-driven testing will pressure it most. Those metrics show whether the organisation can respond at machine speed.

Q: Who is accountable when a misconfigured AI integration or trusted update path is exploited?

A: Accountability should sit with the control owners for identity, application delivery, and risk governance, not only with vulnerability management. If the path involved privileged credentials, build pipelines, or an AI integration, those owners must be part of the remediation and assurance model because the failure crossed multiple domains.

Technical breakdown

Why AI-found vulnerabilities do not map neatly to patch workflows

A model can surface a flaw faster than human research, but discovery speed does not automatically translate into reduced risk. Traditional patch workflows assume a vulnerability is the primary unit of exposure, yet attackers often need only one reachable path, one exposed service, or one over-privileged credential to bypass a long remediation queue. In that sense, AI-assisted discovery increases the volume of findings while leaving prioritisation to the organisation. The harder problem is deciding what is exploitable in your environment, not what exists in the abstract. Practical implication: measure remediation against reachability and business criticality, not against CVE counts alone.

Practical implication: prioritise exposures by exploitability in your environment, not by scan volume alone.

How identity and AI permissions become part of the attack surface

The article’s most important pivot is from code flaws to misconfigured identities, over-permitted integrations, and AI systems with write or execute rights. Those are not conventional vulnerabilities, but they are still attack paths because they govern what an actor can do once authenticated. In NHI terms, service accounts, tokens, and AI agent credentials become high-value control points when they can reach sensitive systems without tight scope boundaries. In agentic AI environments, the same problem appears when tool access is broader than the task. Practical implication: treat AI integrations and service identities as governed access paths, not just application dependencies.

Practical implication: inventory AI and machine identities with the same discipline used for privileged human access.

Why supply-chain trust is now as important as code quality

Cleaner code can reduce the rate of new defects, but it does not remove trust-chain compromise. The article correctly notes that many major incidents begin with a phished maintainer, a compromised developer workstation, or a trusted update channel abused downstream. That is a governance problem as much as a technical one, because it sits across identity verification, signing, access approval, and offboarding. As AI tools speed up software production, the attack surface shifts toward the humans and pipelines that authorise change. Practical implication: link software supply-chain controls to identity assurance, privileged access review, and build-pipeline hardening.

Practical implication: secure the identities behind software delivery, not only the code they produce.

Threat narrative

Attacker objective: The attacker objective is to reach critical systems through a trusted identity or delivery path that scanners and CVE workflows do not reliably surface.

1. Entry occurs when attackers target the human or trust layer rather than waiting for a published vulnerability, using phishing, social engineering, or compromised developer access to gain a foothold.
2. Escalation follows when over-privileged credentials, AI integrations, or trusted update channels give the attacker access beyond the original entry point.
3. Impact occurs when those paths are used to compromise critical systems, move into high-value assets, or launch a supply-chain style breach that bypasses CVE-based defences.

NHI Mgmt Group analysis

Exposure management has outgrown CVE management. The article is right to challenge the assumption that finding more vulnerabilities equals better security. Organisations are increasingly breached through reachable identities, exposed trust chains, and over-permissioned integrations that never appear in a scan result. That means exposure management must join code, identity, and runtime context into one decision model, not a separate queue. Practitioners should treat exploitability and privilege scope as the real security variables.

AI systems are now part of the identity problem, not just the application problem. When AI tools receive write or execute permissions, they become governed actors with the ability to change state, access data, and trigger downstream activity. That places them squarely inside NHI and agentic AI security concerns. The named concept here is AI permission sprawl: the uncontrolled spread of access rights across models, tools, and integrations. Practitioners need to inventory those permissions before they become invisible production dependencies.

Cleaner code does not neutralise trust-chain compromise. Even if major vendors reduce defect volume, attackers still prefer compromised developers, phished approvers, and malicious dependencies because those paths often bypass vulnerability scanners entirely. This is the same governance failure pattern seen in supply-chain incidents: trust is granted too broadly and verified too late. Security teams should therefore judge software risk by who can authorise change, not only by how many flaws the code contains.

Board reporting needs a business-loss frame, not a defect-count frame. The article makes a strong case that boards ask about exposure, not about CVE backlogs. That is the right unit of communication because control failures often span identity, cloud, and software delivery domains. The practical implication is to report attack paths to critical assets, expected loss, and containment capability, with identity and NHI control gaps called out explicitly.

Continuous exposure management is now the bridge between vulnerability, identity, and resilience. Vulnerability management remains necessary, but it is no longer sufficient unless it can answer whether a flaw or misconfiguration is reachable, exploitable, and likely to matter to the business. That puts continuous exposure management alongside IAM, PAM, and NHI governance as a core resilience function. Practitioners should use it to unify remediation priorities across humans, machines, and AI-enabled workflows.

What this signals

AI permission sprawl is likely to become a standing governance problem as organisations give more models and integrations the ability to take action. The operational signal to watch is not just whether a tool is present, but whether it can mutate data, call downstream services, or bypass human review. Teams should align this with NIST AI Risk Management Framework governance and with internal reviews of privileged non-human access.

The practical next step is to collapse separate queues for vulnerabilities, identities, and AI integrations into one exposure view. That gives security leaders a defensible way to explain why a low-volume but reachable path matters more than a long list of unreachable defects. It also creates a cleaner handoff between IAM, PAM, cloud, and application teams when remediation must cross ownership lines.

For practitioners

• Map attack paths to critical assets Build exposure reporting around the systems attackers can actually reach, then weight findings by business impact and exploitability instead of CVSS alone. Use this to expose where a single stolen credential or misconfigured AI integration could matter most.
• Inventory AI and machine permissions Document every AI tool, service account, token, and integration that can write, execute, or access sensitive data. Classify each identity by scope, owner, and revocation path so over-permissioned access becomes visible before it is abused.
• Tie supply-chain risk to identity assurance Require stronger approval, signing, and access review for developers, maintainers, and build pipelines that can release software or models into production. The relevant control gap is often who can authorise change, not whether the code was scanned.
• Reframe board metrics around exposure Replace raw vulnerability counts with metrics for reachable attack paths, privileged identity exposure, and estimated business loss. This gives leadership a clearer view of where remediation effort changes the organisation’s actual risk.

Key takeaways

• AI-assisted vulnerability discovery does not eliminate exposure management gaps, because attackers still win through reachable identities, trust chains, and over-privileged integrations.
• The evidence in the article supports a shift from CVE counting to business-path prioritisation, especially where AI systems can act with broad permissions.
• Security teams should connect vulnerability management, IAM, PAM, and NHI governance into one exposure model that reflects how attacks actually happen.

Key terms

• Exposure management: Exposure management is the practice of identifying which assets are reachable by attackers and reducing that reach before exploitation occurs. For collaboration systems like SharePoint, it is not enough to know that a patch exists, because public accessibility changes the speed and likelihood of attack.
• AI Permission Sprawl: AI permission sprawl is the uncontrolled spread of access rights across models, agents, connectors, and automation tools. It becomes risky when systems can read, write, or execute beyond their intended task, creating hidden paths that traditional vulnerability scans will not detect.
• Trust Chain Compromise: Trust chain compromise occurs when attackers abuse a trusted relationship, such as a maintainer account, update pipeline, or signed dependency, to move into production systems. The weakness is often not the code itself but the authority granted to people and systems that deliver it.
• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.

What's in the full article

XM Cyber's full article covers the operational detail this post intentionally leaves for the source:

• How the Glasswing argument maps to exposure management workflows and board reporting.
• The specific AI and software-supply-chain examples the article uses to show why CVEs are incomplete.
• The author’s breakdown of how human compromise and misconfigured identities shape real attack paths.
• Why the article believes continuous exposure management is the better control model for this risk.

👉 XM Cyber's full post covers the board-risk framing, AI integration exposure, and supply-chain implications in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programmes they operate and defend.