What breaks when approval workflows are built outside the gateway?

Control drift breaks first, followed by fragmented audit evidence. Different teams make different choices about which tools are gated, who may approve, and how long approvals last. Over time, the enterprise loses a single enforceable standard and spends more effort investigating decisions than governing them.

Why This Matters for Security Teams

When approval logic sits outside the gateway, the organisation stops applying one enforceable control point and starts relying on scattered local rules. That creates inconsistent approval thresholds, uneven exception handling, and gaps in evidence collection. The result is not just administrative mess. It is a control failure that weakens least privilege, breaks traceability, and makes it harder to prove who authorised what, when, and under which condition.

This pattern is especially dangerous for secrets and non-human identities because approvals often govern access to API keys, service accounts, and automation tokens rather than one-time human requests. NHIMG notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how quickly governance breaks once controls are distributed. A similar failure mode appears in ??

Security teams also underestimate how quickly workflow drift becomes operational drift. Once teams build approvals into ticketing tools, scripts, chatops, or bespoke apps, the gateway no longer reflects the real policy state. In practice, many security teams encounter approval inconsistencies only after an access review, incident investigation, or audit request has already exposed the gap.

How It Works in Practice

A gateway-centred approval model keeps policy evaluation close to the resource being protected. The gateway can inspect the request context, determine whether the operation is allowed, and enforce time-bound approval conditions before traffic reaches the backend. That matters because approval is not just a yes or no decision. It is also a record of scope, duration, approver authority, and revocation path.

In mature designs, the gateway becomes the policy enforcement point while an identity or policy engine supplies the decision logic. That logic should be consistent with controls such as NIST SP 800-53 Rev. 5, especially access enforcement and auditability expectations, and should map cleanly to NHI governance principles described in Ultimate Guide to NHIs. For human review, the workflow may still live in a ticketing or approval system, but the gateway must remain the final gate that accepts or rejects the session, token, or credential grant.

• Use one approval source of truth for scope, approver, and expiry.
• Issue JIT credentials only after approval, then revoke them automatically at timeout or task completion.
• Log the gateway decision, the reason code, and the policy version that made the decision.
• Bind approval to the workload, not just the requester, so the approved entity cannot be replayed elsewhere.

This also reduces secret sprawl. If approval happens outside the gateway, teams often compensate by embedding tokens in scripts or passing credentials through manual handoffs, which expands exposure. Incidents such as GitHub Action tj-actions Supply Chain Attack and Hard-Coded Secrets in VSCode Extensions show how quickly controls fail when credential handling is separated from enforcement. These controls tend to break down when multiple gateways, proxy layers, and automation paths enforce different approval rules because the enterprise can no longer prove which decision was authoritative.

Common Variations and Edge Cases

Tighter gateway enforcement often increases operational overhead, requiring organisations to balance approval speed against policy consistency. That tradeoff becomes visible in high-change environments where developers, platform teams, and security reviewers all need to move quickly. Current guidance suggests that the answer is not to remove approvals, but to standardise them and keep the final enforcement point close to the asset.

There is no universal standard for workflow design yet, but best practice is evolving around central policy, short-lived credentials, and explicit expiry. Some teams place the request experience in a portal while keeping enforcement in the gateway. Others use policy-as-code to evaluate approvals at request time, then issue an ephemeral token that dies with the session. The important point is that the gateway must remain the system that can actually deny access, not just document that approval happened elsewhere.

Edge cases appear when legacy apps cannot integrate with the gateway, or when service-to-service access is mediated through multiple proxies. In those environments, approval logic often fragments again unless one policy owner defines the authoritative expiry, revocation, and audit requirements. That is why NIST guidance on audit and access control should be paired with the NHIMG view of NHI governance: if the gateway cannot enforce it, the organisation does not truly control it.

Related resources from NHI Mgmt Group

• What breaks when AI governance relies only on approval workflows?
• What breaks when insurance approval workflows still depend on paper handling?
• What breaks when administrator creation is allowed outside PAM workflows?
• What breaks when non-human identities are left outside IGA workflows?