Computer use agents and the identity execution gap in IAM

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Redblock's blog post: Computer use agents can close the last-mile gap between identity governance decisions and execution in disconnected applications, and manual ticketing still leaves IAM outcomes unverified.

Why it matters: It matters because IAM, PAM, and IGA teams need execution proof as much as approval logic, especially where disconnected apps still sit outside API-driven control paths.

Context

Disconnected applications create an identity execution gap when governance systems can approve access but cannot reliably carry out the change in the target application. In practice, that pushes joiner, mover, and leaver work back into tickets, spreadsheets, and manual follow-through, which weakens auditability and increases the chance of stale access.

The article frames computer use agents as a way to execute identity actions through the user interface instead of waiting for custom integrations. That shifts the problem from policy decisioning to verified execution, which is the real governance challenge for long-tail enterprise applications.

Key questions

Q: What breaks when disconnected applications are not brought into identity governance?

A: When disconnected applications sit outside the identity system, provisioning, review, and offboarding become inconsistent and hard to evidence. Access can persist after business need ends, audit trails fragment, and incident response loses confidence in who still has access. The result is not only operational drag but a control gap that weakens the entire identity perimeter.

Q: Why do disconnected apps increase identity and access risk?

A: Disconnected apps increase risk because they break the chain between authentication, entitlement management, and offboarding. When access is created or removed outside central workflows, orphaned accounts, shared credentials, and stale privileges persist longer. That turns routine business applications into hidden access reservoirs, which attackers and auditors both exploit.

Q: How can security teams tell whether identity automation is actually closing the gap?

A: Look for whether the application itself enforces access state changes and leaves an auditable trail. If teams still need emails or tickets to finish a change, automation is only partial. A working programme should reduce manual touchpoints, shorten revocation paths, and make ownership of access decisions explicit.

Q: What should IAM teams do first when moving from manual tickets to automation?

A: Start by documenting the lifecycle events that should trigger access changes, then assign ownership for each rule. That makes it possible to automate safely without guessing which requests are low risk and which need human review. Early clarity prevents workflow sprawl later.

Technical breakdown

Why RPA breaks in disconnected identity workflows

RPA depends on recorded steps tied to fixed selectors, coordinates, or UI states. That makes it deterministic, but also brittle when labels move, modal windows appear, or a page layout changes. In identity operations, that brittleness is not just an automation nuisance. It creates a control gap because the workflow can fail silently after approval, leaving the governance system believing a change was completed when it was not. For disconnected applications that lack stable APIs, the execution layer has to survive UI drift without losing policy intent.

Practical implication: Treat selector fragility as an identity control failure, not just an automation defect.

How computer use agents change identity execution

Computer use agents do not replay a fixed path. They interpret the visible application state, infer the next action from the screen, and adapt when the interface changes. In the article's framing, that makes them useful for identity execution across apps that cannot be integrated directly. The important distinction is that the agent is acting inside a policy-bound boundary, not improvising governance. That means the value is not autonomy for its own sake. The value is that the execution layer can keep pace with the application estate while still operating under identity rules.

Practical implication: Use visual agents where the application changes too often for recorded workflows to stay reliable.

Why before-and-after verification matters for identity assurance

The article's strongest operational point is not the agentic interface work itself, but the verification loop. Identity governance only closes when the system confirms the target state before and after the action, then records proof back into the IGA process. Without that loop, completion is assumed rather than demonstrated. That matters for JML events, privileged access changes, and entitlement removals because the business risk is not only failed automation. It is unverifiable state, which leaves standing access and orphan accounts in place even after an approval exists.

Practical implication: Require post-action state validation and audit evidence for every identity lifecycle change.

Threat narrative

Attacker objective: The practical outcome for an attacker is extended access persistence in applications that governance systems believe have been remediated.

1. Entry occurs through disconnected enterprise applications that cannot be governed by direct API control, forcing identity actions into manual or semi-manual execution paths.
2. Credential or access changes are then carried out through tickets, spreadsheets, or brittle RPA flows that may not complete the requested lifecycle event.
3. Impact is identity debt, where orphan accounts, standing privileges, and incomplete deprovisioning persist despite governance approval.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity governance fails at execution when the control plane cannot prove the target state. Approval workflows are not the same as lifecycle completion, and disconnected applications expose that mismatch. The governance decision may be correct, but without verified enforcement in the application, the control is incomplete. Practitioners need to stop treating execution as an administrative afterthought.

The identity execution gap is a last-mile governance problem, not an automation problem. The article correctly separates policy intent from the act of carrying it out. That distinction matters because many IAM programmes can adjudicate access but cannot reach the long tail of apps where business access actually lives. The implication is that governance maturity now depends on whether execution can scale beyond the front door.

Computer use agents are not the point; closed-loop identity enforcement is. The article's most useful contribution is the idea that interface-adaptive execution only matters if it produces verifiable state change. That shifts the market conversation away from workflow novelty and toward proof of completion, which is where identity assurance lives. Practitioners should judge any execution layer by whether it can synchronize evidence back into governance.

Closed-loop verification is the named concept this article exposes. Identity programmes that cannot compare desired state to actual state after execution are operating with blind spots in their lifecycle controls. The problem is especially acute for JML and privileged access changes in disconnected apps, where manual completion claims are easy to make and hard to validate. The control objective is not more ticketing; it is proof that the identity state actually changed.

Long-tail application coverage is now an identity risk control, not just an operational convenience. The enterprise apps that remain outside API-first automation are often the ones where access lingers longest and cleanup is least reliable. That means the unsupported tail of the portfolio is not a marginal edge case. It is where governance debt accumulates fastest, and where accountability breaks down when no one can show the action was completed.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Read next: Privileged Access Management Guide

What this signals

Closed-loop identity execution: The operational question is no longer whether governance can approve access, but whether the organisation can prove the application state changed. For disconnected apps, that means execution evidence has become part of the control itself, not a postscript to it.

Manual ticketing is still the common failure mode in long-tail applications because it creates a gap between decision and enforcement. For IAM and PAM teams, the meaningful metric is not how many workflows are automated, but how many lifecycle changes end with verified state in the target system.

For practitioners

• Map the disconnected-app backlog Identify the applications where identity changes still depend on tickets, spreadsheets, or manual console work, then rank them by access criticality and remediation pain.
• Require state verification after execution For every joiner, mover, leaver, or privileged access change, confirm the target account state in the application and retain evidence of the before-and-after result.
• Separate workflow approval from completion Redesign identity operations so approval, execution, and verification are distinct checkpoints instead of a single assumed outcome.
• Use guardrailed execution for long-tail apps Reserve computer use agents for applications where API coverage is absent but policy enforcement and audit evidence still have to be maintained.
• Track orphaned state as a governance metric Measure how often approved identity changes fail to produce the intended application state, and treat those misses as control debt rather than back-office noise.

Key takeaways

• Disconnected applications expose the point where IAM approval logic stops and real enforcement begins.
• The article's central risk is unverifiable completion, which leaves standing access and orphaned accounts in place.
• Closed-loop verification is the control that turns identity execution from a promise into evidence.

Key terms

• Identity Execution Layer: The operational layer that turns access decisions into changes inside target applications. In this context, it matters because governance fails when the system that approves access is separate from the system that actually applies it, leaving completion unverified.
• Closed-Loop Identity Assurance: An operating model where identity actions are verified after execution and the resulting state is fed back into governance records. The key feature is evidence, not assumption, so lifecycle changes can be trusted even when the target application is a disconnected or legacy system.
• Disconnected Application: An application that is not integrated with the organisation's central identity and access stack. Access is often managed through shared passwords, manual approval, or local admins, which makes revocation, evidence, and ownership harder to enforce consistently across the application lifecycle.
• Identity Debt: Identity debt is the accumulation of unowned, over-permissioned, or poorly governed non-human identities that security teams cannot cleanly inventory or retire. It usually grows when experimentation outruns access governance, leaving service accounts and tokens active long after their original purpose has passed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.