Lumos Now Governs AWS Account Access Manager Assignments for Human and Machine Identities

Most AWS organizations give people access to accounts in two ways, often at the same time. An engineer might reach production through an AWS IAM Identity Center permission set, or through an IAM role that lives inside the production account. The two can grant exactly the same thing, but they're separate objects, managed in separate places and usually reviewed separately, if they're reviewed at all. An inventory will list both paths, but it won't tell you they overlap. Over time that overlap grows: two paths to the same resources, roles nobody uses, and permissions that widened after their last review.

Those IAM roles are also where human and machine access start to mix. The roles people get assigned to are often the same ones your pipelines and workloads assume, so one role can end up used by both a CI system and an engineer; each granted access a different way.

AWS IAM account access manager, a new AWS service, puts both paths in one place: admins can assign IAM Identity Center users and groups directly to the IAM roles already deployed in the individual accounts within their organization. Lumos now reads those assignments and adds them to the identity graph its security agents already work from, alongside permission sets, IAM roles, service principals and access keys. When an agent reviews someone's AWS access, it can see every way that person authenticated into an account. Lumos only reads what's already in AWS, and flags what's worth a second look.

How it works

You keep your existing setup and the AWS tools that come with it: your roles, tags, condition keys and AWS IAM Access Analyzer.

Lumos reads those entitlements through the account-access API and folds them into insights generated by our AI Agents to get a complete identity picture: IAM Identity Center permission sets, IAM roles, service principals, access keys, and the same employee's the authenticating Entra users can access.

Why Lumos

The Lumos agent reads the assignment, the role's policy, who else holds it and what the tags say about ownership. A reviewer then gets a short list of decisions with the reasoning attached, instead of thousands of rows to certify.

The agent also keeps checking for drift between reviews: duplicate assignments, ownership tags that still point at someone who left, and permission sets that overlap a directly assigned role, which usually means it's time to consolidate on one path. Teams can build custom agents encoding their own policy — production reviewed monthly, iam:PassRole escalates to security, contractors on a shorter clock — and run them on a schedule. A role that picked up extra permissions is a lot easier to deal with when someone catches it within a week instead of at the next quarterly review.

Because Lumos maps machine identities and human access in the same graph, the agent can watch those shared roles: which people sit in roles a service also uses, and who can assume them, pass them or edit their trust policies.

What's next

Next, we plan to use AWS IAM account access manager for provisioning. An access request approved in Lumos by the right owner would become an AAM assignment, and it would be removed the same way when a review says no or the time limit runs out.

Granting access through the same system that reviews it closes the gap where drift usually starts: a change made in the console that your governance tool only hears about on its next sync, if ever. It also means time-bound access expires on schedule, and a review that says no actually removes access.

Lumos would act with credentials scoped to the approver's own permissions instead of a standing integration role, so AWS itself enforces the limit: an agent can't do more in your AWS accounts than the person who approved the action. We also plan to support identity providers beyond Entra ID.

See it in action

Book a demo or reach out to Lumos Support to get started.

‍