Notifications
Clear all
Topic starter
08/06/2026 4:20 pm
TL;DR: Unmanaged cloud, GitHub, or admin grants that slip past normal controls can be turned into immediate notify, review, or revoke workflows, shrinking exposure from days or weeks to minutes, according to ConductorOne. That matters because identity governance fails fastest when exceptions are only caught in periodic review.
NHIMG editorial — based on content published by ConductorOne: Spotting the Unknown: How Grant Found Trigger Automation Strengthens Security
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.
Questions worth separating out
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 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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
ConductorOne's full post covers the operational detail this post intentionally leaves for the source:
- Exact trigger examples for Slack notifications, automatic revocation, and review workflows when grants appear outside C1.
- Practical use cases for AWS, GCP, and GitHub entitlement cleanup, including inherited versus direct access handling.
- How the automation is intended to reduce response time from days or weeks to minutes in live workflows.
- Examples of how app owners and security teams can route discovered grants into validation and remediation paths.
👉 Read ConductorOne's analysis of grant found trigger automation and shadow access →
Grant found trigger automation: what it means for IAM teams?
Explore further
08/06/2026 5:54 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Grant found trigger automation exposes unmanaged access gaps in IAM
