Policy-driven identity governance for access reviews and approvals

At a glance

What this is: This is a blog post about policy-based identity governance in ConductorOne, with the key finding that layered policies can automate access requests, approvals, and reviews using real-time conditions.

Why it matters: It matters because the same policy logic that speeds human approvals also shapes how teams govern NHI, autonomous, and human access at scale, especially where review paths and escalation rules need to stay consistent.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read ConductorOne's blog on policy-driven access governance in C1

Context

Policy-driven access governance is a way to turn review and approval logic into rules that can be evaluated in context instead of hard-coded one approver at a time. In practice, that means the real question is not whether policy exists, but whether it captures the identity, entitlement, and operational signals that determine who should decide.

For identity programmes, this matters because the governance model must scale across humans, NHI, and increasingly autonomous systems without collapsing into manual exception handling. If the logic behind approval routing is too rigid, teams end up with bottlenecks, inconsistent decisions, and policies that drift away from how access is actually used.

For the broader NHI governance model, the relevant comparison is not just human approvals versus automation. It is whether policy logic can preserve review integrity when the subject is a service account, token, workload, or agent that changes context faster than a traditional access process can keep up. The Ultimate Guide to NHIs is the clearest baseline for that governance model.

Key questions

Q: How should teams design policy-based access reviews without creating workflow sprawl?

A: Teams should define one authoritative rule set for broad access logic, then allow narrower entitlement rules only where there is a real exception. The goal is to reduce duplicate workflows while keeping decision ownership clear. A good policy model is auditable, layered, and explicit about which context triggers a different approval path.

Q: Why do real-time policy decisions still fail in identity governance programmes?

A: They fail when the attributes feeding the policy engine are stale, incomplete, or inconsistent with how the business actually operates. The policy may execute correctly, but it will still produce the wrong outcome if role data, on-call status, or entitlement mapping is outdated. Governance quality depends on the identity data pipeline, not just the rules.

Q: What do security teams get wrong about automated approval routing?

A: They often assume automation removes governance complexity, when it really relocates it into policy design, fallback handling, and attribute quality. If the policy is too rigid or the data too noisy, the system becomes fast but not trustworthy. Automation should reduce manual work, not hide decision ambiguity.

Q: Should organisations use the same policy model for humans and non-human identities?

A: No. Humans, service accounts, and tokens may all sit inside identity governance, but they should not share the same approval assumptions. Human review flows rely on managers and business context, while NHI governance needs lifecycle, scope, and entitlement controls that reflect machine behaviour and persistence.

Technical breakdown

Dynamic approval routing in policy-based governance

Policy engines in identity governance evaluate rules at runtime, using attributes such as group membership, role, time, or operational state to determine who should approve a request. That is different from static workflows, where a task is always sent to the same person or queue. The technical value is not merely automation. It is conditional routing that can change as the subject, entitlement, or surrounding context changes. In layered systems, policies may apply at the application, entitlement, and review levels, allowing one rule to cascade across multiple decision points without duplicating workflow logic.

Practical implication: map approval logic to the least stable attribute set you can trust, then test whether the same rule behaves correctly across app, entitlement, and review layers.

Policy layering across application, entitlement, and review

Layering policies means the system can apply broad governance logic at the application level, more specific rules at the entitlement level, and fine-grained decision criteria at the review stage. This structure reduces one-off workflow sprawl, but it also creates dependency between layers. If the top layer is too broad or the lower layer is too narrow, review paths can become inconsistent or redundant. The architecture works best when each layer answers a different question: should this app follow this policy, should this entitlement be treated differently, and who should make the final decision.

Practical implication: separate broad access policy from entitlement-specific exceptions so teams can audit where a decision was made and why it changed.

Real-time attribute evaluation and governance drift

Real-time evaluation is the part of policy-driven governance that keeps decisions aligned to current conditions, such as on-call status or senior engineer designation. The technical risk is that attributes can become stale, incomplete, or misaligned with business reality even when the policy engine is working correctly. When that happens, the system may still execute exactly as designed while producing poor governance outcomes. In other words, the failure is often not the workflow, but the trustworthiness of the attributes the workflow consumes.

Practical implication: review upstream attribute sources first, because policy quality is bounded by the freshness and correctness of the identity data it reads.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salt Typhoon US telecoms breach — Salt Typhoon APT used stolen credentials and Cisco CVE to breach US telecoms.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Policy engines expose the limits of static identity governance. The article shows that access decisions can be made dynamically, but the governance problem does not disappear when the workflow becomes more intelligent. It shifts to whether the inputs, layers, and fallback paths still reflect the actual identity model. For practitioners, the real test is whether policy logic reduces exception handling without obscuring accountability.

Layered approval logic creates policy sprawl unless organisations define decision ownership clearly. When application, entitlement, and review policies can all influence the same access path, teams need a clear model for which layer is authoritative in a dispute or exception. Otherwise, the governance programme becomes technically sophisticated but operationally ambiguous. Practitioners should treat policy layering as a control architecture, not just a workflow feature.

Identity governance for NHIs depends on the same policy discipline, but the subject changes. A policy model that works for human managers and reviewers may not translate cleanly to service accounts, tokens, or workload identities if the entitlements themselves are long-lived or machine-triggered. That is why the strongest NHI governance programmes focus on the policy boundary, not just the approval event. The implication is that access governance must be designed around actor type, not around a single approval pattern.

Real-time decisioning is a governance strength only when the underlying identity data is trustworthy. Policies that react instantly to on-call status, role, or group membership can only be as accurate as the data feeding them. If upstream identity attributes drift, the policy engine can reinforce bad decisions at scale. Practitioners should read this as a reminder that policy logic and identity data quality are inseparable.

Policy-based governance is becoming a shared control plane for human, machine, and delegated access. The more enterprises rely on unified policy logic, the more they need a consistent way to express who can decide, under what conditions, and with what override path. That convergence is where identity governance, PAM, and NHI lifecycle management start to overlap. The practical conclusion is that policy design now belongs in the architecture conversation, not only in operations.

From our research:

• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how often policy design outruns lifecycle governance.
• For the lifecycle angle, the NHI Lifecycle Management Guide is the next step for teams that need to connect access rules to provisioning, rotation, and offboarding.

What this signals

Policy-based governance is most effective when it is treated as an identity control plane, not a workflow convenience. The practical shift for programme owners is to align policy logic, lifecycle data, and review ownership before scaling automation, because the failure mode is usually inconsistent decision authority rather than missing approval steps. The NIST Cybersecurity Framework 2.0 is a useful reference point for tying policy design back to govern and protect functions.

Policy cascades create a useful pattern for NHI governance, but only if the underlying entitlements are already clean. Once access paths become layered, the programme needs stronger entitlement hygiene, clearer owner assignment, and better exception tracking, otherwise automated routing simply propagates ambiguity faster. That is where the Top 10 NHI Issues becomes operationally relevant.

Policy layering should now be read as part of the broader identity lifecycle problem. If review logic and offboarding logic are not aligned, the organisation can approve access correctly and still fail to remove it when the identity changes. With 96% of organisations storing secrets outside secrets managers in vulnerable locations, per Ultimate Guide to NHIs, the governance gap is often structural rather than procedural.

For practitioners

• Map policy ownership by decision layer Document which team owns the application, entitlement, and review layers, then define which layer wins when rules conflict or exceptions are required.
• Validate attribute sources before expanding policy logic Check whether on-call status, role assignments, and group membership are current, because stale source data can produce perfectly executed but incorrect decisions.
• Separate human approval logic from NHI governance paths Use different policy patterns for human reviewers and machine identities so service accounts and tokens do not inherit approval assumptions meant for people.
• Use policy cascades to reduce workflow sprawl Consolidate repeated approval logic into reusable rules at the broadest layer that still preserves entitlement-specific exceptions.

Key takeaways

• Policy-driven access governance can reduce approval bottlenecks, but only when the decision logic matches real identity conditions.
• Layered workflows improve scale, yet they create a new governance requirement: clear ownership of each policy layer and its inputs.
• For NHI and human programmes alike, the real control is not automation itself but whether the policy model stays aligned with lifecycle and attribute truth.

Key terms

• Policy Engine: A policy engine is the decision layer that evaluates rules and attributes to determine what action should happen next. In identity governance, it can route approvals, assign reviewers, or trigger fallback logic. Its value depends on how accurate the inputs are and how clearly ownership is assigned.
• Policy Layering: Policy layering is the practice of applying different rules at different decision points, such as application, entitlement, and review. It improves scale and precision when it is deliberate. It becomes risky when layers overlap without a clear authority model or exception path.
• Attribute-Based Decisioning: Attribute-based decisioning uses identity, role, and operational attributes to make access decisions at runtime. It is more flexible than fixed approver lists, but only if the underlying attributes are current and trustworthy. Poor data quality turns flexible policy into automated error propagation.
• Review Routing: Review routing is the process of assigning an access review or approval task to the person or group most appropriate to decide. In mature governance programmes, routing reflects context such as ownership, role, or operational status, not just a static manager chain.

Deepen your knowledge

Policy-based identity governance and layered approval design are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance across humans, service accounts, and delegated access, it is worth exploring.

This post draws on content published by ConductorOne: The Power of Policies in C1. Read the original.