What are the signs that identity governance is being asked to do runtime enforcement work?

A common sign is when audit evidence shows who authorised an agent and what it could access, but nothing shows whether the specific action was allowed at execution time. Another signal is repeated reliance on static scopes to control state-sensitive operations such as transfers, cross-tenant reads, or approval-dependent writes. That is a control boundary problem, not a logging problem.

When governance is being used as the enforcement layer

Identity governance is meant to answer who should have access, who approved it, and whether that access should still exist. When it starts being used to decide, in real time, whether a specific action may proceed, the control boundary has shifted. The system may still produce clean audit trails, but the decision has moved from governance into runtime authorisation.

That usually shows up when teams expect access reviews, entitlements, and approval records to block a transfer, a cross-tenant read, or a sensitive write at the moment it happens. Those controls can inform policy, but they do not replace an enforcement point that can evaluate the current state of the request.

Why static scopes stop being enough for state-sensitive actions

Static scopes are effective when access is stable and the only question is whether a subject should generally be allowed to call an API or enter a system. They are much weaker when the decision depends on mutable context, such as transaction status, tenant boundaries, approval state, freshness of consent, or whether the action would alter a protected record.

In those cases, identity governance can confirm that a principal exists, was reviewed, and was granted a role or entitlement. What it cannot reliably do by itself is inspect the exact runtime conditions that make one call safe and another unsafe. If a transfer can only happen after a separate approval, or a write must be denied once a workflow state changes, the denial has to happen in the runtime control path.

What the evidence gap looks like in practice

The easiest way to spot the problem is to look at the evidence teams rely on during review. If the record shows who authorised an agent or service, and what broad permissions were granted, but there is no trace of the execution-time decision for the individual action, then governance is carrying a job it cannot actually prove.

This often appears in environments that have strong review cadence but weak decision telemetry. The team can answer “who approved this identity?” yet cannot answer “why was this specific sensitive action allowed right then?” That gap matters because the action may depend on state that changes faster than any review cycle. The IAM and IGA Basics guide is useful here because it separates governance, entitlement management, and enforcement.

Risk and Threat Considerations

When governance is treated as runtime enforcement, the main risk is false confidence. Teams believe an approval trail or periodic certification is preventing misuse, while the actual execution path still permits actions that should have been denied in the moment. That creates exposure for privileged transfers, cross-tenant reads, and approval-dependent writes.

Failure mechanism: The request is authorised once at a broad entitlement level, but the sensitive action is never re-evaluated against current state, workflow status, or transaction context at execution time.

Impact: A stale or overly broad entitlement can permit an action that should have been blocked, and the organisation only discovers the gap after review, dispute, or incident analysis.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-3 — Access Enforcement	Runtime action checks are an access enforcement problem, not just governance.
	AU-2 — Event Logging	The question depends on whether execution-time decisions are observable in logs.
	IA-5 — Authenticator Management	Static credentials and scopes can hide lifecycle weaknesses that governance cannot correct at runtime.
Recommendation — Enforce each sensitive action at execution time, not only at approval or review time. Log the runtime authorization decision for sensitive actions. Manage credentials and token scope so stale authority does not outlive its intended use.
NIST CSF 2.0	PR.AA-05 — Identity Management, Authentication, and Access Control are Managed	The issue is whether access control is actually enforced at the point of use.
Recommendation — Separate governance approval from runtime access enforcement for sensitive operations.
OWASP API Security Top 10	API5 — Broken Function Level Authorization	State-sensitive writes and transfers fail when broad permission is mistaken for per-action authorization.
Recommendation — Validate that each sensitive function is authorised for the current request context.

Practitioner Guidance

What to verify: Check whether every high-impact action has an enforcement decision at the point of execution, not just an approval or recertification record. If the only evidence is “who approved access,” treat that as incomplete for state-sensitive operations.

Decision rule: If the risk depends on current transaction state, approval state, tenant context, or record state, keep governance as the policy and ownership layer, and require a separate runtime control to enforce the decision. If you cannot name the enforcement point, the control is probably missing.

Practitioner takeaway: Governance is the place to define and review authority, but runtime enforcement must decide the action when the state can change between approval and execution.