TL;DR: Traditional RPA is brittle for disconnected enterprise apps because interface changes break recorded workflows, while computer use agents can adapt visually and support policy-bound identity execution with before-and-after verification, according to Redblock. The deeper issue is that identity governance fails when the execution layer still depends on manual tickets and unverifiable completion, not on the agentic label itself.
NHIMG editorial — based on content published by Redblock: The Nuance of Automation: RPA vs Computer Use Agents
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.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
Q: How should security teams handle disconnected applications that sit outside identity tooling?
A: Treat disconnected applications as part of the identity perimeter, not as exceptions to ignore.
Q: Why do disconnected apps create so much IAM risk?
A: Disconnected apps create risk because identity changes no longer propagate automatically, so access can outlive the business event that should have removed it.
Q: What breaks when RPA is used as the final control for access administration?
A: RPA breaks when UI changes, selector drift, or modal pop-ups interrupt the recorded path.
Practitioner guidance
- Define the identity execution boundary Map which applications still depend on manual fulfilment, ticket queues, or brittle UI automation, then classify them as lifecycle risk zones rather than low-priority edge cases.
- Require before-and-after state validation Make successful completion a measured control by comparing target application state before and after every joiner, mover, leaver, or privileged access action.
- Synchronise execution evidence back to governance records Feed proof of execution into IGA and PAM so access reviews, offboarding records, and audit trails reflect what the destination system actually contains.
What's in the full article
Redblock's full article covers the operational detail this post intentionally leaves for the source:
- A direct comparison of RPA, computer use agents, and identity execution for disconnected apps.
- The before-and-after validation model used to confirm lifecycle completion in target systems.
- How governance decisions are synchronised back into IGA records after execution.
- The product framing for turning manual identity tasks into policy-bound workflow execution.
👉 Read Redblock's analysis of computer use agents versus RPA for identity execution →
Computer use agents and the identity execution gap , are your controls ready?
Explore further
Policy without verified execution is not identity control. In disconnected application estates, approvals often end at the ticketing layer while the real state change happens elsewhere or not at all. That creates a governance illusion: the programme believes access was changed, but the target system may still reflect the old state. The practical conclusion is that identity control must include proof of execution, not just policy intent.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- Only 97% of NHIs carry excessive privileges is not the problem statement here, but it shows why enforcement gaps in long-tail applications become attack surface quickly.
A question worth separating out:
Q: How can organisations prove that identity automation reduces risk?
A: Organisations can prove risk reduction by showing that automation shortens the time to revoke access, removes standing privilege faster, and cuts down on orphaned accounts or stale entitlements. They should also track reductions in high-risk access combinations and compare those changes to breach exposure models.
👉 Read our full editorial: Computer use agents and the identity execution gap in IAM