Who should approve or revoke a grant found outside policy?

Why This Matters for Security Teams

When a grant falls outside policy, the real question is not just whether access is excessive, but who has the authority to justify, accept, and remove it without turning the issue into a permanent exception. In NHI environments, that distinction matters because service accounts, API keys, and agent credentials often outlive the workflow that created them. NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and 90% of IT leaders say properly managing NHIs is essential for successful zero trust implementation.

That is why approval and revocation should not sit with a single team by default. The business owner should validate whether the grant still serves a legitimate purpose, while the identity or platform team should enforce the policy outcome and remove access when the decision is clear. This separation reduces the risk that unmanaged access becomes no one’s problem, especially when the evidence lives across CI/CD, cloud, and vault systems. Current guidance aligns with the control themes in the OWASP Non-Human Identity Top 10 and NHI Mgmt Group’s NHI lifecycle management guidance.

In practice, many security teams encounter this only after an orphaned grant is discovered during audit, not through a clean approval workflow.

How It Works in Practice

A workable process starts by separating decision rights from execution rights. The owner of the workload, application, or business process approves the grant only if they can explain the operational need, the duration, and the compensating controls. The identity, security, or platform team then applies the policy decision, including revocation, restriction, or time-bound exception handling. That model is consistent with the broader NIST Cybersecurity Framework 2.0, which expects accountable governance and controlled access decisions rather than informal ownership.

For NHI controls, the mechanics should be explicit:

• Check whether the grant maps to an approved service, integration, or automation path.
• Require an accountable owner who can confirm the business need and accept the risk if policy exceptions are necessary.
• Use the platform or identity team to enforce the outcome, because they control the system of record, token issuance, and revocation.
• If ownership is unclear, place the grant in exception handling and time-box the review until accountability is assigned.
• Record the decision, evidence, and expiry date so the grant does not become a hidden permanent entitlement.

This is especially important where secrets are embedded in automation, because revocation often requires coordination across code, vaults, and runtime environments. NHI Mgmt Group’s regulatory and audit perspective and the static vs dynamic secrets guidance both reinforce that revocation must be operationally real, not just documented. These controls tend to break down when ownership is embedded in a shared platform team but the consuming workload is run by multiple product teams, because no single group can verify business need quickly enough to act.

Common Variations and Edge Cases

Tighter approval and revocation control often increases operational overhead, so organisations must balance speed against accountability. That tradeoff is real in environments with short-lived deployments, delegated admin models, or many ephemeral NHIs created by CI/CD pipelines.

Best practice is evolving for shared services and agentic systems. In some cases, the requester and the approver are the same team, but that only works when segregation of duties is still preserved through independent review or automated policy checks. In other cases, the grant may be technically owned by a platform team while the business risk sits with a product owner, which means both roles have to participate before revocation or approval is final. If the environment uses high-velocity automation, current guidance suggests using pre-approved patterns for common grants and routing everything else through exception handling rather than making ad hoc approvals normal.

Where governance is weakest, the main failure mode is not bad intent but ambiguous accountability. That is why the safest answer is still: the business owner validates need, the identity or platform team executes the change, and unresolved ownership blocks the grant until a named decision maker is assigned. This approach is aligned with the NHI risks documented in NHI Mgmt Group’s Top 10 NHI Issues.

Related resources from NHI Mgmt Group

• What should organisations do when mobile device management and identity policy conflict?
• What breaks when one identity can create, approve, and pay invoices?
• What breaks when one person can create and approve the same financial transaction?
• What breaks when one role can approve and execute the same transaction?