Grant found trigger automation exposes unmanaged access gaps in IAM

At a glance

What this is: This post explains how grant found trigger automation detects unmanaged access and converts it into immediate security actions such as notify, review, or revoke.

Why it matters: It matters because IAM programmes often fail at the exception layer, where direct grants and privilege escalations bypass normal workflows and leave exposure open until the next review cycle.

👉 Read C1.ai's analysis of grant found trigger automation and unmanaged IAM access gaps

Context

Access becomes a governance problem when it is granted outside the control paths a programme expects. In this case, the issue is unmanaged permission changes in AWS, GCP, and GitHub that do not flow through normal identity governance workflows.

The practical gap is not detection alone. Security teams need a way to turn a newly found grant into an immediate decision, because a periodic review process is too slow for access that can be created manually in seconds.

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 teams know if grant found automation is actually working?

A: They should look for shorter time to decision, fewer unmanaged grants surviving into the next review cycle, and a lower volume of unresolved exceptions. If discovery still leaves access open for long periods, the automation is alerting but not governing.

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

A: They should validate whether the access was expected, determine whether it fits the approved inheritance or provisioning model, and revoke it if it does not. The goal is to remove standing exception access before it becomes a durable attack path.

Technical breakdown

How grant found triggers detect shadow access

A grant found trigger fires when the system discovers access that exists outside the intended provisioning path. In practice, that means the discovery layer is watching for new permissions, roles, or repository entitlements that were not created through the governed workflow. This is not the same as generic alerting, because the trigger is tied to the access object itself and can be used as an event source for downstream automation. Practical implication: build response logic around the discovery of an ungoverned grant, not around periodic certification alone.

Practical implication: tie response automation to the appearance of an unmanaged grant, not to the next audit cycle.

Why direct grants break least-privilege models

Direct assignment bypasses the inheritance and approval structure that IAM and IGA programmes rely on. When a user receives a role in AWS or GCP, or a repository permission in GitHub, outside the expected path, the access may technically work while remaining invisible to the model that was supposed to govern it. That creates a gap between policy and reality, especially where permanent access appears in a context designed for temporary or inherited access. Practical implication: classify direct grants as control exceptions, not routine entitlements.

Practical implication: treat direct grants as policy exceptions that need validation, not as ordinary access.

How automated revocation shortens exposure windows

The value of the trigger is that it allows security teams to move from discovery to decision immediately. A discovered grant can trigger notification, review, or revocation, which means the organisation does not have to wait for a human to notice the issue in a later review cycle. That matters because exposure time is often the difference between a contained misgrant and a usable attack path. Practical implication: define policy thresholds that let the automation revoke access when the grant clearly violates the approved model.

Practical implication: use policy thresholds that allow automatic revocation when a grant clearly violates the approved model.

Threat narrative

Attacker objective: The attacker or insider aims to preserve unauthorised access long enough to use it for privilege abuse, persistence, or lateral movement before governance catches up.

1. Entry occurs when access is granted manually in AWS, GCP, or GitHub outside the normal identity governance path.
2. Escalation happens when a high-privilege or permanent grant bypasses team-based inheritance and remains active without review.
3. Impact follows when unmanaged access broadens the attack surface and leaves over-privileged accounts available for abuse until the next audit cycle.

Breaches seen in the wild

• Scania insurance portal breach 2025: An attacker used an external user login, likely stolen by infostealer malware, to take insurance claim documents from a Scania portal.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow access is a governance failure, not just a detection problem. The article shows that unmanaged grants become dangerous because they exist outside the lifecycle controls that IAM programmes assume are in place. When a role or repository permission is created manually, the programme may still look healthy while the real access state has drifted. The practitioner lesson is that discovery must feed governance action immediately, or the control plane never sees the exception.

Grant found automation shifts the control point from certification to issuance. Periodic access reviews assume the risky access will still be present when the review happens. That assumption is increasingly weak in cloud and SaaS environments where access can be created outside policy and exploited before the next review window. The implication is that governance has to react at the moment of grant creation, not only at recertification.

Direct entitlement paths create identity blast radius. A manual admin grant in AWS, GCP, or GitHub can create a much larger effective blast radius than teams expect because it sidesteps inherited access structures. That makes privilege management a question of where access originated as much as who holds it. The practitioner conclusion is that the source of the entitlement must be part of the control decision.

Least privilege fails when exception handling is weak. The article’s central pattern is not that least privilege is impossible, but that unmanaged exceptions accumulate faster than governance teams notice. This is where programmes become brittle: the policy says one thing, the live entitlement graph says another. The field takeaway is that least privilege requires real-time exception handling, not only policy documentation.

Identity governance now depends on automated response loops. The move from notify to review to revoke reflects a wider shift in how identity control is executed. In environments with multiple cloud and SaaS ownership models, the governance function cannot rely on a single manual team to reconcile every unexpected grant. Practitioners need to treat automation as part of the control architecture, not an afterthought.

What this signals

Identity governance has to move closer to issuance. Grant-found automation shows that the useful control point is no longer the periodic certification review. Security teams need to watch for unmanaged access at the moment it appears, then convert that event into a governed decision path before the entitlement becomes normalised.

Exception handling is now part of least privilege. If your environment still relies on manual admin changes in cloud or SaaS systems, the real risk is not just excess access, but ungoverned access that never enters the review queue. Programmes that cannot see direct grants in near real time will continue to miss the control gap that matters most.

For practitioners

• Map unmanaged-grant sources Identify where direct permissions can still be created outside your governed provisioning path in AWS, GCP, and GitHub.
• Classify direct grants as exceptions Route manually assigned roles and repository permissions into an exception workflow instead of treating them as routine entitlements.
• Trigger immediate review on discovery Configure detection events so that unexpected grants create a review task the moment they are found, not at the next certification cycle.
• Allow automatic revocation for clear violations Define policy thresholds that let the automation revoke access when the grant clearly falls outside approved inheritance or provisioning paths.
• Track exposure time for unmanaged access Measure how long unexpected grants remain active from discovery to removal so you can prove whether the control loop is actually tightening.

Key takeaways

• Unmanaged grants are dangerous because they sit outside the identity governance path and can stay active long enough to be exploited.
• The article’s core evidence is operational, not theoretical: direct cloud and GitHub permissions can be found, reviewed, or revoked the moment they appear.
• Security teams should treat discovery of unexpected access as a control event, because speed of decision is what turns exposure into containment.

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.
• Unmanaged Grant: An unmanaged grant is an access entitlement created outside the approved identity workflow, such as a manual cloud role assignment or direct repository permission. In governance terms, it is live access that exists in production but was never cleanly authorised through the expected control process.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Exception Workflow: An exception workflow is the path an alert follows from detection to investigation, remediation, and closure. In mature control environments, it identifies who owns the issue, what evidence must be retained, and how the organisation proves the exception was handled correctly.

What's in the full article

C1.ai's full blog post covers the operational detail this post intentionally leaves for the source:

• Examples of how the grant-found trigger can route unmanaged access into Slack notifications or workflow tasks
• Scenario-specific guidance for high-privilege cloud roles, temporary access, and direct GitHub entitlements
• Operational examples of when to notify, when to review, and when to revoke based on the access source
• Practical discussion of visibility across app owners when access is created outside the governed path

👉 The full C1.ai post covers trigger-based notification, review, and revocation patterns for unmanaged access

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.