Applied AI for vulnerability management: what Cogent’s market guide implies

At a glance

What this is: This is Cogent’s interpretation of AI-native vulnerability management, with the key finding that effective remediation depends on reconciling scope, sequencing work, and verifying outcomes.

Why it matters: It matters because vulnerability programmes fail when ownership, evidence, and execution are disconnected, which is also where identity and access controls determine whether automation can be trusted.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Cogent's analysis of AI-native vulnerability management in SACR's 2025 Market Guide

Context

Applied AI for vulnerability management is really a governance problem about whether remediation can be turned into a controlled, repeatable workflow. The article’s core point is that organisations do not just need more findings, they need reliable scope, ordered action, and proof that changes actually landed. That makes this topic relevant to IAM and NHI practitioners because ownership, entitlements, and execution rights determine whether remediation can be automated safely.

Cogent frames the problem around three failures: scope is fragmented across systems, sequence is constrained by dependencies and maintenance windows, and verification is often too weak to prove business impact. For identity teams, that maps directly to who can change what, which service accounts or agents can act on behalf of the programme, and how those actions are logged. In other words, the article is about control planes as much as it is about vulnerability data.

Key questions

Q: How should security teams use AI without turning it into a control dependency?

A: Security teams should use AI for summarisation, correlation, and prioritisation, then keep containment in deterministic controls such as access policy, segmentation, and revocation. The key rule is that AI can recommend action, but it should not be the only mechanism that can stop exposure. That separation reduces false confidence and preserves auditability.

Q: Why does ownership matter so much in remediation workflows?

A: Because remediation fails when no one can prove who is responsible for each asset, issue, or change. Ownership links the finding to the right team, the right approval path, and the right evidence trail. Without it, prioritisation becomes noisy, tickets bounce between groups, and the organisation cannot show that risk actually decreased.

Q: What breaks when verification is treated as ticket closure?

A: The programme measures activity instead of risk reduction. A closed ticket does not prove the change was applied, persisted, or was effective on the intended asset. That gap creates audit exposure and operational blind spots, especially when multiple systems and teams are involved in the fix.

Q: Should organisations treat remediation agents like privileged identities?

A: Yes. Any agent that can change assets, update records, or trigger workflows is acting through delegated authority and should be governed accordingly. That means least privilege, scoped access, logging, and review. If an agent can modify production state, it belongs in the same control conversation as other privileged identities.

Technical breakdown

Entity resolution is the foundation of scoped remediation

Entity resolution is the process of reconciling different labels, IDs, and records so systems agree on what asset or owner is actually being discussed. In vulnerability management, that matters because the same server, workload, or application often appears differently across scanners, CMDBs, cloud platforms, and ticketing systems. AI can help map duplicates and enrich context, but it only works when the underlying record is treated as the system of truth. Without that, remediation plans are built on inconsistent data and ownership gaps rather than verified state.

Practical implication: establish a single asset and ownership record before automating remediation workflows.

Role-tuned AI agents need bounded authority

Role-tuned AI agents are specialised workflows that produce actions for a specific persona such as security, IT, or application ownership. The technical risk is not the recommendation itself, but whether the agent can act with the right scope, time window, and rollback path. That is an identity and access problem as much as an AI problem, because each agent needs explicit permissions, traceable delegation, and auditable limits. If the agent can see more than it can safely change, the workflow becomes a privilege management issue.

Practical implication: map each remediation agent to narrowly scoped permissions and logged approval paths.

Verification must prove change at the asset level

Verification is the control that distinguishes completed work from assumed work. In practice, that means proving the intended change occurred on the relevant asset, at a known time, and with evidence that can survive audit. AI can accelerate triage and orchestration, but it cannot replace evidence collection. If verification is only ticket closure or scanner rerun timing, the programme measures activity rather than risk reduction. Mature workflows tie the action, the identity that performed it, and the post-change state together.

Practical implication: require asset-level evidence linked to the actor, time, and remediation outcome.

NHI Mgmt Group analysis

AI-native vulnerability management is really a control-plane problem, not a reporting problem. The article’s three-part framing of scope, sequence, and verification reflects where remediation programmes usually fail: the data is incomplete, the work is not ordered, and the outcome is not proved. That makes the category less about finding more issues and more about governing the change process itself. For practitioners, the implication is that remediation automation must be judged on control quality, not output volume.

Identity is the hidden dependency inside vulnerability orchestration. When an AI workflow can assign owners, open tasks, and trigger changes, it is operating through delegated authority. That means IAM, PAM, and service identity governance become prerequisite controls, not adjacent disciplines. The same logic applies to workload agents that enrich or repair records: if their permissions are broad or opaque, the remediation system becomes a privileged automation layer that needs the same scrutiny as any other high-trust identity.

Verification debt is the named risk this model exposes. Organisations often record that a task was created or a ticket was closed, then assume risk has been reduced. In reality, the control gap is the lack of evidence that the change landed on the intended asset and stayed in effect. That gap is especially serious when automation spans multiple teams and systems. For practitioners, the lesson is to treat proof of change as a first-class governance requirement.

Applied AI only scales when it is constrained by least privilege and traceability. The article’s emphasis on isolated data, complete logs, and human approval shows the practical boundary for AI in security operations. AI can accelerate prioritisation and sequencing, but it must remain inside an auditable workflow with clear delegation. That is the line between useful automation and unmanaged operational risk, and it should shape programme design from the start.

What this signals

Verification debt will become the most useful lens for evaluating AI-assisted remediation programmes. If teams cannot prove that changes landed on the intended asset and were executed by the right identity, then automation is only accelerating administrative work, not reducing exposure. That is why identity governance, auditability, and evidence retention need to be designed into the workflow from the start.

The practical signal for security leaders is that remediation platforms will increasingly be judged by delegation quality, not just triage speed. If an agent can sequence work, it must also operate inside Lifecycle Processes for Managing NHIs style controls, because delegated change execution is still privileged activity. For programmes already scaling automation, the control question is simple: can you show who acted, on what, and under what scope?

For practitioners

• Define a single remediation source of truth Reconcile scanner output, CMDB records, cloud inventory, and ticketing data so every remediation plan points to one asset record and one accountable owner. Without that baseline, AI-generated sequencing will amplify inconsistencies instead of reducing them.
• Bind remediation agents to explicit delegated authority Issue narrowly scoped permissions for each security, IT, or application agent, with time limits, approval gates, and rollback paths. Treat those agents as identities that must be governed, logged, and reviewed like any other privileged actor.
• Require evidence-based closure for every fix Close remediation only when you have asset-level proof that the change landed, the affected control is in place, and the result is attached to the responsible identity and timestamp. Ticket closure alone should never count as verification.
• Sequence work around business constraints Order fixes by dependency, maintenance windows, and risk tolerance rather than by queue position alone. That keeps AI-supported remediation aligned to operational reality and reduces the chance that automation creates outages or failed change windows.

Key takeaways

• AI-native vulnerability management succeeds when scope, sequencing, and verification are governed as one workflow rather than three separate tools.
• Identity, privilege, and evidence are central controls in automated remediation because the system is only as trustworthy as the delegated actors inside it.
• Programmes that cannot prove asset-level change are accumulating verification debt, which weakens both operational resilience and audit confidence.

Key terms

• Entity Resolution: Entity resolution is the process of determining which accounts, wallets, devices, or records belong to the same real-world actor. It is essential for sanctions and AML programmes because transaction data alone often hides related activity unless it is linked back to a trusted identity model.
• Security Debt: Accumulated risk that builds when vulnerabilities, unsafe dependencies, and policy gaps are left unresolved across the software lifecycle. In AI-assisted development, security debt grows quickly because more code is produced, more decisions are made automatically, and remediation often lags behind delivery.
• Delegated Agent Authority: The permission granted to an AI agent to act on behalf of a human user or another agent, inheriting some or all of their access rights. Delegated authority must be explicitly scoped, time-limited, and auditable.

What's in the full article

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

• Customer-reported workflow examples showing how AI-native remediation is used in practice.
• The article's own framing of entity resolution, planning, and verification as product capabilities.
• Vendor examples of how operators keep humans in the loop while allowing scoped automation.
• The surrounding market context from SACR's Market Guide that informed the analysis.

👉 Cogent's full post covers the market guide framing, customer-reported outcomes, and product-oriented interpretation.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and lifecycle controls that matter when automation relies on delegated authority. It is designed for practitioners who need to govern identity-driven workflows across modern security programmes.