What should security teams do when a direct grant appears in GitHub or cloud IAM?

What a direct grant actually signals

A direct grant is an explicit exception to the normal inheritance or provisioning model. In GitHub or cloud iam, that usually means someone bypassed group membership, role assignment, or automated lifecycle controls to give access straight to a user, service, or workload. The security question is not just whether the grant exists, but whether it is consistent with the approved control plane for that identity.

That distinction matters because direct grants are harder to inventory, easier to overlook during recertification, and more likely to survive long after the original business need has changed. A grant that looks harmless in isolation can become a standing path into production systems, repositories, or secrets if no one is responsible for its expiry.

For teams managing cloud privilege at scale, the practical test is whether the access came from the expected inheritance path or was applied as an exception. NHIMG’s Cloud PAM and CIEM Guide is useful here because it frames direct access against effective permissions, overprivilege, and rightsizing rather than against the nominal role name.

Why direct grants create governance and access risk

Direct grants are risky because they weaken traceability. When access is granted outside the standard model, reviewers have to prove why it exists, who owns it, and when it should end. That extra burden often means the permission remains in place longer than intended, especially in GitHub orgs, cloud subscriptions, or cross-account setups with many administrators.

They also create hidden privilege spread. A small direct grant can become a durable exception that escapes normal joiner-mover-leaver processes, especially when the grant is attached to a human account, a service principal, or a workload identity that is assumed to be temporary. The result is a control gap between what the policy says should exist and what the platform actually allows.

NHIMG’s NHI Lifecycle Management Guide is relevant because the same lifecycle problem appears whenever access is provisioned outside the intended provisioning, rotation, and offboarding flow. For background on the broader problem space, Top 10 NHI Issues also covers excessive permissions and access governance failures that often begin as one-off exceptions.

How teams should assess and remove the grant

The right response is to compare the direct grant against the approved access model before deciding whether it stays. If the access is expected, document the inheritance path or provisioning reason so it can be reviewed later without guesswork. If it is not expected, remove it and reissue access through the sanctioned role, group, or entitlement path so future reviews can rely on standard controls.

In cloud environments, that usually means checking whether the grant was compensating for a missing role design, a broken automation flow, or an emergency change that was never cleaned up. In GitHub, it may mean confirming whether the direct permission was needed for repository administration, workflow execution, or token-based automation, then converting it to a managed group or app-based pattern where possible.

NHIMG’s Cloud Workload Identity Guide is a good companion for this review because it distinguishes managed, keyless access patterns from ad hoc credentials and direct assignments. Where direct grants are part of pipeline or automation access, CI/CD Pipeline Identity Security Guide helps teams re-anchor the access in a controlled workload identity path rather than in a lingering exception.

Risk and Threat Considerations

Direct grants become dangerous when they are treated as temporary convenience instead of as privileged exceptions. The longer they remain in place, the more likely they are to be abused, inherited by automation, or forgotten during role changes and offboarding. In GitHub and cloud IAM alike, a standing exception can give an attacker exactly what they want: a legitimate-looking path that bypasses normal approval and least-privilege design.

Failure mechanism: The exception is granted outside the standard entitlement model, then survives because nobody owns its expiry or can easily see its business justification. That lets access drift from approved intent into standing privilege.

Impact: The organisation inherits a durable attack path, weaker auditability, and a higher chance of privilege misuse, especially where the direct grant reaches repositories, admin functions, deployment systems, or secrets.

Practitioner Guidance

What to verify: Confirm whether the grant maps to an approved exception, a documented break-glass need, or a missing entitlement design. If none of those exist, treat it as unmanaged access rather than as an ordinary permission.

Decision rule: If the access cannot be re-expressed through the normal inheritance or provisioning path, remove the direct grant and fix the underlying access model. If the same exception appears repeatedly, escalate it as a control-design problem, not a one-off cleanup task.

What good looks like: Direct grants are rare, time-bounded, named to an owner, and reviewed against an inventory that shows who approved them and why they still exist.

Practitioner takeaway: The key judgement is whether the grant is a controlled exception or an unmanaged shortcut, because only the former belongs in a durable security model.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?