TL;DR: C1.ai says its integration with AWS IAM Account Access Manager centralises AWS role assignment, just-in-time provisioning, access reviews, and risk detection across Identity Center and IAM roles. The practical shift is less manual cleanup and more consistent governance, but the underlying control problem remains how to manage standing privilege and orphaned access at scale.
At a glance
What this is: C1.ai's AWS IAM Account Access Manager integration brings AWS role assignment, just-in-time provisioning, access reviews, and risky-access detection into one governance flow.
Why it matters: It matters because IAM teams need a single control plane for AWS access decisions, especially when roles, account assignments, and temporary access all need to stay auditable and least-privileged.
👉 Read C1.ai's analysis of AWS IAM Account Access Manager governance and JIT access
Context
AWS access governance breaks down when role assignment, approval, review, and revocation live in separate workflows. In that model, teams can technically grant access quickly while still losing track of who can assume which role, why the access exists, and whether it should still be active.
C1.ai's integration is aimed at that coordination problem across AWS IAM Account Access Manager and IAM Identity Center. The governance challenge is not creating roles, but keeping account assignments, reviews, and temporary access aligned as AWS estates grow.
Key questions
Q: How should teams govern AWS role assignments across Identity Center and account access managers?
A: Treat them as one entitlement governance problem, not two provisioning tools. Security teams should consolidate visibility, approvals, and review evidence so the same role cannot appear governed in one workflow and unmanaged in another. The goal is a single source of access truth for who can assume a role, why it exists, and when it should disappear.
Q: When does just-in-time access reduce cloud risk?
A: Just-in-time access reduces cloud risk when standing privilege is the main problem and the baseline permissions are already tightly scoped. If the default role is overly broad, temporary access only shortens exposure time without fixing the entitlement model. Teams should use JIT after they have reduced excess privilege and clarified ownership.
Q: What breaks when AWS access reviews do not include all role assignment paths?
A: Reviewers lose the complete entitlement picture and may certify only part of the access estate. That creates blind spots for shared roles, account assignments, and temporary grants, which means evidence quality drops even if the campaign appears complete. A review process is only as strong as the access paths it can actually see.
Q: When should organisations prioritise orphaned AWS access over broader entitlement cleanup?
A: When roles exist without clear ownership or business justification, because those grants are the hardest to defend and the easiest to overlook. Unowned access signals a lifecycle problem, not just a reporting issue, so it should be removed or reassigned before teams move on to lower-risk entitlement cleanup.
How it works in practice
How AWS IAM Account Access Manager changes role assignment
AWS IAM Account Access Manager provides a central place to assign AWS IAM roles to users and groups from IAM Identity Center, whether the identity source is a synced directory or the native directory. The important architectural detail is that it does not replace the role model; it links identity objects to existing IAM roles across accounts. That means provisioning can be simplified without forcing a redesign of the AWS permission structure. For governance teams, the control question shifts from how many systems create access to how consistently those systems are reflected in one authoritative access view. See the Cloud Workload Identity Guide.
Practical implication: keep the role model intact, but consolidate assignment visibility so governance does not fragment across AWS workflows.
Why just-in-time provisioning matters for AWS role governance
Just-in-time provisioning creates time-bound access only after an approval or policy decision, then revokes it automatically when the grant expires. In identity terms, that reduces the lifetime of elevated access from an open-ended entitlement to a bounded access event. The governance value is not only speed for the requester. It is that temporary access no longer needs manual cleanup and does not linger as standing privilege after the task is complete. That matters most where AWS roles are powerful, shared across accounts, or granted only for specific work periods. See the NHI Lifecycle Management Guide.
Practical implication: use time-bound grants for exceptional AWS access instead of leaving temporary permissions to manual revocation.
How access review campaigns handle AWS account assignments
The integration feeds AWS role assignments into existing access review campaigns, which matters because review only works when the reviewer can see the full entitlement context. If AWS account assignments are split between Identity Center permission sets and separate role pathways, reviewers have to learn multiple processes or they miss a portion of the access picture. By placing those assignments into one campaign flow, the review process can ask the real governance question: who should still be able to assume the role, and on what basis? Read the Ultimate Guide to NHIs: Regulatory and Audit Perspectives.
Practical implication: run reviews on the complete AWS entitlement set, not only on the subset created by one provisioning path.
NHI Mgmt Group analysis
Standing AWS role assignment is the control problem, not role creation. The article is really about governance over access pathways that already exist in AWS. When role assignment, review, and revocation are split across systems, teams can preserve the architecture while still losing control of who can assume what. The practitioner takeaway is that AWS access governance has to focus on assignment state, not just account inventory.
Just-in-time access is only useful when revocation is automatic. Time-bound access changes the governance unit from a persistent entitlement to a temporary decision. That matters because the risk is not simply over-provisioning, but access that survives after the work is done. Teams should treat expiry as part of the control, not a cleanup task.
Access reviews fail when the entitlement graph is incomplete. If AWS role assignments are split between IAM Identity Center and AWS IAM Account Access Manager, reviewers do not have a trustworthy picture of effective access. That creates a blind spot in certification campaigns and weakens evidence quality. Practitioners need a single entitlement context before review can mean anything.
Orphaned AWS access is a lifecycle failure, not a reporting issue. The detection of unowned or risky roles points to a deeper governance gap: access exists without accountable ownership. That is a lifecycle problem that extends beyond AWS, but it becomes especially visible in cloud estates where permissions are easy to create and hard to retire. NHI lifecycle management remains the right lens for the offboarding side of the problem.
Identity graph context is becoming the practical control plane for AWS governance. The more access is represented alongside SaaS, cloud, and on-premises entitlements, the easier it becomes to ask whether a role is still necessary, who owns it, and whether policy should block future requests. The implication is that AWS governance is moving toward identity-centric decisioning, not isolated account administration.
Read next: NHI Lifecycle Management Guide
What this signals
Access governance for AWS is shifting from static entitlement tracking to decision-time control. The relevant question is no longer only who has a role, but whether that role was granted for a current need, can be reviewed in context, and will expire without manual intervention. That change favours identity-centric programmes that can govern issuance, review, and revocation together.
Temporary AWS access should be treated as a lifecycle state, not a ticket outcome. When the grant itself carries expiry and the review campaign sees the same entitlement graph used for provisioning, the organisation is much closer to governable least privilege than it is with scattered account-level administration.
For cloud programmes, the practical benchmark is whether orphaned access can be identified before it becomes normalised. If the governance model cannot surface unowned roles in the same place where teams approve and review access, the programme is already operating with incomplete visibility.
For practitioners
- Unify AWS entitlement visibility Map IAM Identity Center assignments and AWS IAM Account Access Manager role links into one reviewable entitlement inventory so governance teams can see the full access path. Read the Ultimate Guide to NHIs: Regulatory and Audit Perspectives.
- Make temporary AWS access expire automatically Require time-bound grants for elevated AWS access and let expiry remove the access without manual cleanup or exception tracking.
- Review orphaned and unowned roles first Prioritise roles that lack clear ownership or have no current business justification, then move them into the next access campaign before expanding review scope.
- Keep the AWS role model intact Preserve existing IAM role structure while changing how assignments, approvals, and revocations are governed across accounts and directories.
Key takeaways
- The article is primarily about consolidating AWS access governance across role assignment, just-in-time provisioning, and review workflows.
- The main risk is not new role creation but standing, orphaned, or unowned access that becomes harder to audit at scale.
- The most relevant control shift is from manual cleanup to automatic expiry and a single entitlement view for AWS roles.
Related NHI Mgmt Group resources: NHI Lifecycle Management Guide · Ultimate Guide to NHIs: Regulatory and Audit Perspectives · Cloud Workload Identity Guide · Top 10 NHI Issues
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on reducing standing AWS role privilege and governing who can assume roles. |
| NHI-01 — Improper Offboarding | Orphaned and unowned roles point to lifecycle gaps in removing AWS access when need ends. | |
| NHI-07 — Long-Lived Secrets | Time-bound access directly addresses the persistence of AWS credentials and role grants. | |
| Recommendation — Reduce standing AWS role exposure by governing assignment, expiry, and review under NHI-05. Apply NHI-01 to revoke or reassign AWS roles that no longer have an accountable owner. Use NHI-07 to replace persistent AWS access grants with short-lived, automatically expiring access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about governing AWS entitlements, role assignments, and access reviews. |
| Recommendation — Align AWS role governance to PR.AA-05 by reviewing entitlements and authorisations in one control process. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Automatic expiry and revocation of temporary AWS access maps to credential lifecycle governance. |
| Recommendation — Enforce IA-5 to manage AWS authenticator lifecycle, including issuance, expiry, and revocation. | ||
Key terms
- Just-in-Time Provisioning: Just-in-time provisioning creates an account or entitlement at the moment it is needed, then removes it later. It reduces standing access duration, but it still relies on a static identity or role existing during the access window, which leaves room for misuse if revocation lags.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
- Entitlement Graph: A mapped view of who or what has access to which systems, roles, and privileges. It provides the operational basis for review, certification, and segregation-of-duties analysis. Without it, teams rely on disconnected reports that cannot reliably prove control effectiveness.
- Orphaned Access: Orphaned access is credentialed access that still works even though no clear business owner can justify or manage it. It usually appears after system changes, reorganisations, or integrations, and it is especially dangerous because it can remain active long after the original purpose has disappeared.
What's in the full announcement
C1.ai's full post covers the operational detail this post intentionally leaves for the source:
- How the AWS IAM Account Access Manager integration maps into existing IAM role structures without redesigning AWS permissions
- The exact bidirectional just-in-time provisioning flow for approved AWS account and role access
- How AWS access review campaigns present IAM Identity Center assignments and AWS IAM Account Access Manager roles together
- The detection logic for unowned, orphaned, or otherwise risky AWS role assignments
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.
Published by the NHIMG editorial team on October 21, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org