Imagine we’ve built a handy little Lambda function that reads incoming files, transforms them, and writes the results. The demo works. Happy days. And someone asks whether it can run in production by Friday. Naturally, Friday means this Friday, and it’s currently EOD Wednesday.
The application gets tests, monitoring, and a deployment pipeline. Its permissions get a ticket marked “refine later.” And we’ve just added baked-in identity debt to the release, with no fixed review date.
AWS (Amazon Web Services) gives us clear guidance for this, but we still need someone responsible for following it.
What AWS IAM role manager actually creates
AWS IAM (Identity and Access Management) role manager automates role setup in supported service consoles. In its custom-code Lambda example, AWS attaches PowerUserAccess because it cannot know beforehand which services our code needs.
Crucially, AWS’s August 2026 explanation recommends disabling role manager and refining the resulting roles before production. Disabling it leaves existing roles in place.
Disabling the feature doesn’t revoke the permissions it already granted.
The principle of least privilege means granting only the access required for an intended task. Getting our function running is the starting point. Demonstrating least privilege in AWS requires another decision before release.
Give “refine later” an owner and a deadline
The person who created a role isn’t necessarily the person responsible for the service today. Identity provenance tells us where access came from; ownership tells us who must justify it now.
For each prototype role, record the application, account, environment, service owner, deployment repository, and review deadline.
Then we need to divide the work clearly:
- The service owner explains required behavior, including recovery.
- Platform engineering implements and tests narrower permissions.
- Security defines release blockers and reviews exceptions.
- The release process requires evidence that the change is deployed.
This is practical identity governance, with an actual finish line.
AWS’s September 2026 IAM remediation guidance connects findings to pull requests for infrastructure-as-code roles and issues for manually created roles. That’s a useful delivery pattern. A ticket, however, is a container for work. It isn’t proof the work happened.
Narrow IAM permissions using evidence
For our file-processing function, combine IAM Access Analyzer findings with application requirements, code review, and representative tests. Access Analyzer costs money; however, our Trustle free trial can help by analyzing the activity.
Then we should consider what the evidence covers. Did we exercise retries, backfills, failed writes, scheduled jobs, and recovery? Did the observation period include the operations that happen only occasionally?
AWS’s June 2026 guidance on unused encryption keys shows the pitfalls of relying on inactivity alone: a key can show no recent use yet remain necessary for future decryption or disaster recovery.
When we narrow the role created by AWS IAM role manager, usage history should guide the review. It can’t tell us everything the function legitimately needs. A recovery permission might be essential even if it hasn’t been used yet. Conversely, a permission exercised during prototype testing might have no place in production.
Before release, test the narrower role against both requirements and boundaries: can the function still read its incoming files and write the results? Is it denied access to unrelated datasets and operations it doesn’t need? That gives us evidence that we’ve removed excess permissions without breaking the workload.
Which permissions should block production?
For this workload, we should hold the release when:
- Broad service access remains without a documented requirement.
- The function can reach unrelated datasets, secrets, or encryption keys.
- Unnecessary deletion or security-configuration permissions remain.
- Trust relationships or other consumers of the role are unexplained.
- We lack sufficient evidence to approve the proposed policy safely.
These are suggested release criteria, adapted to the application.
Review broad permissions by what they actually allow. As AWS’s April 2026 policy guidance explains, available restrictions vary by service and operation. That makes context essential: what can this role access, what does it use, and what does the workload need? Here at Trustle, we bring entitlement visibility and usage insights together to support those reviews, helping us identify excess access and make informed permission changes.
Any exception needs a named risk owner, compensating controls, an expiration date, and a follow-up decision. “Temporary” needs a concrete entry in the security calendar.
Verify the broader access didn’t survive elsewhere
Removing one policy attachment doesn’t finish the investigation.
First, inspect the running function’s actual role and permissions. Next, update its deployment definition so the next release cannot restore the old configuration. Finally, check shared consumers, copied roles, and resource policies for equivalent access.
AWS’s August 2026 S3 remediation guidance addresses bucket policies and account-level controls, reinforcing why resource-side access deserves attention.
Otherwise, we risk celebrating a clean role while shadow access continues to lurk in the wings.
Keep the before-and-after policy, test results, approval, and deployment evidence together. Centralize that review history and use automated identity tracking to surface permission changes over time, so we can verify that removed access stays removed without repeatedly checking roles across AWS accounts.
Making permission cleanup part of delivery
Useful cloud entitlement management connects visibility to decisions and completed remediation. Our role at Trustle is helping our clients understand access, identify excess, and support informed remediation.
It’s important to track ownerless roles, overdue exceptions, and verified remediation thoughtfulness. Finding more problems is useful; closing them safely is the outcome.
AWS IAM role manager can accelerate the prototype. Our release process must finish the permission review. “Later” needs an owner and an ending.
Explore the Trustle free trial to bring AWS entitlements into one view, identify excessive or unused permissions, and use activity context to guide role reviews. Centralized visibility and automated identity tracking help us follow permission changes over time without repeatedly checking roles across AWS accounts. Get started in as little as 30 minutes, then use those insights to narrow and justify AWS IAM permissions before production—and keep them under review afterward.
You can thank us later.
