Identity’s semi-async middle is where automation fails

At a glance

What this is: This is an analysis of why identity automation breaks in the semi-async middle layer, where workflows are too brittle for trust and too supervised to deliver real delegation.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes all suffer when identity work is half-automated, half-manual, and impossible to govern cleanly at scale.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read Redblock's analysis of the semi-async identity middle layer

Context

Identity automation fails when organisations treat every workflow as if it should behave the same way. The real problem is the semi-async identity middle layer, where tasks are too slow to feel interactive, too fragile to trust, and too dependent on human babysitting to count as real delegation.

That matters for IAM and NHI governance because the control model changes depending on whether a task needs immediate human context, durable automation with evidence, or autonomous execution with auditability. If teams do not separate those modes, they end up measuring workflow activity instead of actual identity control.

Redblock frames this as a placement problem rather than a tooling problem, and that distinction is typical of how mature identity programmes eventually think about operational scale.

Key questions

Q: How should security teams decide which identity controls to automate first?

A: Start with high-volume, repeatable tasks that create delay when handled manually, such as access review routing, entitlement reminders, and offboarding follow-up. Then preserve human approval for exceptional or high-impact access changes. The best candidates are controls that reduce exposure time without removing accountability from the workflow.

Q: Why do semi-async identity workflows create more governance risk than manual tasks?

A: They create risk because they look controlled while still depending on humans to catch failures. Manual tasks are slow but visible. Semi-async workflows can stall, drift, or break silently, which means identity changes, offboarding, and compliance evidence can all diverge from reality before anyone notices.

Q: What breaks when identity automation stops at connected applications?

A: Lifecycle management breaks first, then access review quality, then confidence in the overall identity programme. If a meaningful share of applications still relies on manual administration, the organisation loses consistency and cannot prove that identity controls extend across the full estate. The result is partial governance disguised as maturity.

Q: Who is accountable when an autonomous identity exceeds intended scope?

A: Accountability sits with the programme owners who defined the lifecycle, access, and monitoring model, not with the software actor itself. If no team owns actor classification, delegated authority, and revocation, then the gap is organisational, not technical. Governance must assign responsibility before the system acts.

Technical breakdown

Why the semi-async identity middle layer breaks automation

Semi-async workflows sit between synchronous interaction and fully asynchronous delegation. They start as automated tasks, but they still require human supervision because the systems around them are brittle: connectors fail, approvals stall, CSV jobs drift, and UI-dependent bots break when the interface changes. In identity operations, that creates a false sense of control. The workflow appears automated, but the operating model still depends on a person noticing and rescuing failures before they become access or compliance gaps.

Practical implication: classify each identity workflow by execution mode so you can stop treating supervised automation as if it were trusted automation.

How autonomous identity agents change execution and accountability

Autonomous identity agents are different from workflow bots because they are expected to own a task from trigger to evidence. In this model, the agent does not merely suggest a change or wait for approval at each step. It performs the action, captures proof, and handles edge cases under governance boundaries. That shifts identity control from job completion to responsibility assignment. The technical issue is not whether an agent can act, but whether the surrounding identity architecture can record what it did, why it did it, and where human review must still intervene.

Practical implication: define evidence capture, decision boundaries, and human override points before allowing autonomous execution in identity operations.

Why disconnected apps make identity governance harder

Disconnected apps are where identity programmes often lose determinism. API-only controls work well until a target system lacks a clean integration path, forcing teams into manual steps or UI automation. That is where governance slips, because access changes, offboarding, and PAM actions no longer happen in one consistent transaction. The result is a fragmented control plane where some systems are governed through policy and others through exception handling. Identity programmes that ignore this distinction usually confuse coverage with control.

Practical implication: map disconnected applications separately and decide whether they need API governance, UI-assisted execution, or manual handling with compensating controls.

NHI Mgmt Group analysis

The semi-async identity middle layer is a governance failure, not an efficiency gap. Identity programmes do not fail here because teams lack dashboards or workflows. They fail because the operating model asks people to supervise automation that is neither trustworthy nor fully delegated. The implication is that control design must start with execution mode, not with another layer of orchestration.

Autonomous execution changes the accountability model that IAM teams have built around reviewable work. Access reviews, ticket queues, and manual evidence collection presume that a task persists long enough to be observed and certified. That assumption breaks when the workflow is genuinely autonomous and completes before a human review cycle can even begin. Practitioners need to rethink what constitutes a governable identity event, not just add more approvals.

Identity blast radius becomes the right concept for measuring semi-async risk. The issue is not only whether a workflow succeeds, but how far a failure can spread before anyone notices. In disconnected environments, a single stalled or misfired identity action can create orphaned access, delayed offboarding, or incomplete privilege revocation across multiple systems. Teams should treat the spread of failure as a primary design constraint.

Disconnected-app governance is now a lifecycle problem across human, NHI, and autonomous identities. The same operational weakness appears when service accounts, user access, or AI-driven execution depends on brittle handoffs. Lifecycle controls only work when ownership, evidence, and revocation all travel with the identity across the whole path. Practitioners should stop treating each identity class as an isolated programme and start governing the execution chain.

Identity work placement is the named concept that matters here: some tasks belong in human context, some in auditable autonomy, and the middle is where assurance collapses. That middle layer creates a false economy because it looks automated while still consuming human effort at failure points. The practical conclusion is that identity teams must deliberately place each workflow in the mode that matches its risk and repeatability.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• Explore Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for lifecycle controls that reduce identity drift.

What this signals

Identity teams should expect more pressure to prove where automation ends and delegation begins, especially as disconnected apps remain common in day-to-day operations. The practical signal is that governance maturity will be judged less by workflow volume and more by how cleanly teams can place each identity task into a defensible execution model.

Identity work placement: the next stage of IAM maturity is deciding whether a task belongs in human context, supervised automation, or auditable autonomy. That matters because a semi-async process can consume more effort than a manual one while delivering less assurance than a truly delegated one.

With only 20% of organisations reporting formal offboarding and revocation processes for API keys in our research, the operational gap is already visible. Teams that cannot revoke, evidence, and verify consistently will struggle to scale identity governance across both NHI and autonomous workflows.

For practitioners

• Classify identity workflows by execution mode Separate tasks into synchronous human review, supervised automation, and fully delegated autonomous execution so the control model matches the actual work. Use that classification to stop approving workflows that only look automated on paper.
• Map disconnected apps to their control path Inventory which applications can support API-based governance, which require UI-assisted execution, and which still need manual handling with compensating controls. Use that map to prioritise offboarding, PAM rotation, and continuous compliance work where the risk is highest.
• Define evidence requirements for autonomous identity actions Require every delegated identity action to produce auditable proof, including what changed, when it changed, and which boundary conditions applied. That evidence should be reviewable without reconstructing the workflow from logs after the fact.
• Reduce supervision debt in identity operations Find where teams are still babysitting automations that should either be made truly autonomous or moved back into deliberate human workflows. The goal is to remove the hidden human effort that accumulates around brittle identity automation.

Key takeaways

• The semi-async middle layer is where identity programmes lose assurance, because workflows are automated in theory but supervised in practice.
• Identity governance improves when teams distinguish human-paced work, supervised automation, and auditable autonomous execution instead of blending them together.
• Disconnected apps, weak evidence capture, and delayed revocation make identity placement a control issue, not just an operational inconvenience.

Key terms

• Semi-Async Workflow: A semi-async workflow is a process that runs partly in the background but still depends on human attention to finish cleanly. In identity operations, it often creates false confidence because the task appears automated while hidden delays, failures, or exceptions still need manual rescue.
• Identity Work Placement: Identity work placement is the discipline of deciding whether a task belongs in human context, supervised automation, or autonomous execution. It matters because misplacing a workflow creates weak assurance, unnecessary friction, or hidden operational debt across IAM, PAM, and NHI programmes.
• Supervision Debt: Supervision debt is the accumulated human effort required to keep brittle automation functioning. In identity programmes, it shows up when teams spend more time watching, rescuing, and patching workflows than they would spend running a process intentionally with the right control model.

What's in the full article

Redblock's full blog post covers the operational detail this post intentionally leaves for the source:

• The full walkthrough of the semi-async valley model and the identity execution modes behind it
• Specific examples of connector failures, CSV drift, and approval bottlenecks in production identity workflows
• The article's own framing of autonomous identity agents and where Redblock believes they belong in the stack
• The closing product context on replacing ticket-driven identity execution with continuous lifecycle enforcement

👉 Redblock's full blog post covers the execution model, disconnected-app friction, and the case for autonomous identity tasks.

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.