Topic starter
08/06/2026 4:20 pm
TL;DR: C1.ai says grant found trigger automation turns unmanaged AWS, GCP, and GitHub permissions into immediate notify, review, or revoke workflows, cutting exposure from days or weeks to minutes. The underlying issue is that periodic review still misses direct grants and privilege escalations that happen outside normal IAM control paths.
Editorial analysis by NHI Mgmt Group, based on content published by C1.ai: “Spotting the Unknown: How Grant Found Trigger Automation Strengthens Security”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Unmanaged grants are dangerous because they sit outside the identity governance path and can stay active long enough to be exploited.
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
👉 Read C1.ai's analysis of grant found trigger automation and unmanaged IAM access gaps →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/06/2026 5:54 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Grant found trigger automation exposes unmanaged access gaps in IAM
This post was modified 4 days ago by NHI Mgmt Group