Grant found trigger automation exposes unmanaged access gaps in IAM

At a glance

What this is: Grant found trigger automation converts newly discovered unmanaged access into immediate IAM actions such as notification, review, or revocation.

Why it matters: It matters because IAM programmes across NHI, autonomous, and human identity domains need real-time handling for grants that bypass normal provisioning and review paths.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read ConductorOne's analysis of grant found trigger automation and shadow access

Context

Grant found automation addresses a basic IAM problem: access that appears outside the normal provisioning path is often the access most likely to be missed. In practical terms, that includes manual AWS role grants, direct GitHub permissions, and ad hoc cloud entitlements that bypass policy controls.

For NHI programmes, the issue is not discovery alone but what happens the moment discovery happens. The relevant question is whether the governance layer can turn an unmanaged grant into a deterministic action fast enough to limit privilege exposure and reduce the time an exception remains live.

Key questions

Q: What breaks when access is granted outside the normal IAM workflow?

A: When access is granted outside the normal IAM workflow, the governance model loses visibility and the entitlement may remain live long enough to be abused or audited as a finding. The practical failure is not just bad provisioning. It is the gap between discovery and action, which lets unmanaged grants become standing exposure.

Q: Why do unmanaged grants create more risk than approved access changes?

A: Unmanaged grants create more risk because they bypass the controls that define who approved the access, why it exists, and when it should be removed. Without that chain of accountability, teams cannot easily prove legitimacy or limit exposure. That is especially true for direct cloud roles, repository permissions, and other exceptions.

Q: How do you know if access discovery automation is working?

A: Access discovery automation is working when newly found grants are quickly classified, routed, and either approved or removed before they become part of the steady state. Useful signals include shorter containment times, fewer unresolved exceptions, and a declining share of direct grants versus inherited access.

Q: Who should approve or revoke a grant found outside policy?

A: The owner who can validate the business need should approve the grant, while the identity or platform team should enforce the policy decision. If ownership is unclear, the grant should stay in exception handling until accountability is assigned. That prevents unmanaged access from becoming nobody’s problem.

Technical breakdown

Grant discovery as an access event

Grant discovery is the point at which an IAM platform recognises a privilege assignment that did not flow through the expected approval or provisioning path. The trigger becomes meaningful when discovery is treated as an event source, not a report. That means the platform can evaluate the grant against policy, identity source, and entitlement context immediately. In cloud environments, this is especially important because direct assignments to AWS, GCP, or GitHub can bypass team inheritance and create governance blind spots before a human review cycle ever starts.

Practical implication: wire discovery events to policy checks so unmanaged grants do not wait for the next access review.

Trigger automation for notify, review, and revoke

Trigger automation sits between detection and enforcement. A new grant can produce different outcomes depending on its risk level, source, and intended inheritance model. A low-risk exception might route to an owner for validation, while a high-privilege grant outside the approved path can be revoked automatically. The architecture matters because it turns entitlement discovery into a controlled workflow instead of a passive alert stream. That is how teams reduce exposure windows from audit-cycle timing to near-real-time containment.

Practical implication: define policy tiers so high-risk grants trigger revocation while lower-risk exceptions trigger review.

Inherited access versus direct access

Inherited access is access granted through a parent object such as a team or role, while direct access is assigned explicitly to a user or identity. The distinction matters because direct grants often bypass the governance model that was designed to keep access consistent and reviewable. In systems like GitHub, direct repository permissions can be legitimate, but they should be the exception, not the norm. When direct access becomes routine, the programme loses a key signal that access has drifted outside its intended structure.

Practical implication: compare direct entitlements against the intended inheritance model and treat exceptions as governance defects.

Threat narrative

Attacker objective: The objective is to convert an unmanaged grant into durable access that can be abused before governance detects and removes it.

1. Entry occurs when a manual admin action creates a grant outside the approved identity workflow, such as a direct AWS role assignment or repository permission.
2. Escalation follows when the new entitlement gives the identity broader rights than the governance model intended, allowing privilege expansion before review catches it.
3. Impact is the exposure window created by unmanaged access, where over-privileged accounts remain active long enough for misuse or compliance failure.

Breaches seen in the wild

• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

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

NHI Mgmt Group analysis

Grant discovery only matters when governance can act on it immediately. The value is not in seeing another alert but in converting an exception into a policy decision while the access is still live. That is why access governance programmes need event-driven enforcement, not just retrospective review. Practitioners should treat unmanaged grants as control failures until proven legitimate.

Direct entitlements are a structural drift signal, not just an access detail. When teams rely on inherited access models but allow frequent direct grants, the governance model becomes inconsistent with the way privileges are actually assigned. That inconsistency is where review processes lose fidelity and owners lose accountability. Practitioners should measure direct-grant volume as a sign of model erosion.

Shadow access is the named concept this feature exposes. Shadow access is any entitlement that exists outside the normal provisioning, inheritance, or approval path and therefore escapes standard governance visibility. In NHI-heavy environments, shadow access is often the first step toward privilege creep, audit failure, or delayed incident response. Practitioners should treat it as a recurring operating condition, not an isolated exception.

Real-time revoke logic changes the economics of privilege exposure. If the platform can remove a high-risk grant the moment it is discovered, the attacker or careless administrator has less time to exploit it. That does not eliminate the root cause, but it materially shortens the blast radius. Practitioners should align response speed to the sensitivity of the entitlement path.

This problem spans human, NHI, and delegated access governance. The same failure pattern appears when a person, service account, or app owner can create access outside the primary control plane. The governance lesson is broader than one product feature: identity programmes need one policy model for discovering, validating, and retiring exceptions across all actor types. Practitioners should unify exception handling across identity classes.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• For a deeper governance baseline, review NHI Lifecycle Management Guide alongside Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs.

What this signals

The operational signal here is that discovery must become enforcement, not reporting. In environments where access can be created outside the main control plane, the programme needs a fast path from finding to decision to action. Teams that still depend on periodic recertification will continue to carry unresolved exceptions far longer than they should.

Shadow access: access that exists outside the normal provisioning or inheritance model will keep showing up wherever app owners can bypass central governance. That means IAM teams need a single exception-handling model that spans cloud roles, repository permissions, and delegated administration. The broader signal is that review cadence alone cannot compensate for weak control boundaries.

NHI visibility and lifecycle controls are the foundation for making this kind of automation useful, not noisy. With the Ultimate Guide to NHIs as a baseline, teams can map discovery events to ownership, offboarding, and revocation paths before exceptions accumulate.

For practitioners

• Classify unmanaged grants as policy exceptions Route any access discovered outside approved provisioning paths into a formal exception workflow before it is allowed to persist. Separate legitimate business exceptions from true control bypasses so the response path is clear.
• Automate risk-based responses by entitlement type Use different actions for different grants, such as immediate revocation for high-privilege cloud roles and owner review for lower-risk direct permissions. Keep the decision logic tied to entitlement sensitivity, not just detection confidence.
• Measure direct-grant drift across systems Track how often access is assigned directly rather than through the intended inheritance model in AWS, GCP, and GitHub. Rising direct-grant volume is a sign that the governance model is being bypassed.
• Connect discovery events to review owners Make sure every newly found grant has a clear owner who can validate legitimacy quickly, especially where app owners manage access outside central IAM. Without an accountable reviewer, trigger automation becomes another alert stream.

Key takeaways

• Grant found trigger automation matters because unmanaged access is often the most dangerous access.
• The scale of the visibility problem is already material, which is why real-time response is now a governance requirement.
• Teams should treat discovery events as policy decisions and route them into revocation, review, or exception handling immediately.

Key terms

• Grant Found Trigger: A grant found trigger is an automation event that fires when a new access entitlement is discovered outside the expected provisioning path. It turns discovery into an operational decision point, allowing teams to notify, review, or revoke access before the exception becomes normalised.
• Shadow Access: Shadow access is entitlement that exists outside the intended governance path, such as a direct cloud role, repository permission, or manually assigned privilege. It creates blind spots because the access is real, active, and potentially high risk, but not governed the way approved access is supposed to be.
• Inherited Access: Inherited access is permission granted through a parent object, such as a team, group, or role, rather than assigned directly to the identity. It improves consistency and reviewability because the entitlement follows the governance model instead of bypassing it with one-off grants.
• Direct Entitlement: A direct entitlement is access assigned explicitly to an identity instead of flowing through a parent group or role. It is often legitimate, but it becomes a governance concern when it is common, hidden, or used to bypass the intended inheritance model.

Deepen your knowledge

Grant discovery, access exception handling, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls around unmanaged cloud and repository access, it is a relevant place to start.

This post draws on content published by ConductorOne: Spotting the Unknown: How Grant Found Trigger Automation Strengthens Security. Read the original.