AWS Just Taught Data Agents to Carry a Human's Identity. Your Access Model Still Assumes They Don't.
November 2, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
When a natural-language data agent queries your lakehouse, AWS can now carry the actual identity of the person who asked the question all the way into Lake Formation's permission check, instead of collapsing every request into one shared service role. That change, built on IAM Identity Center's trusted identity propagation, fixes a specific audit and access gap that has made AI data agents hard to govern responsibly.
What problem does trusted identity propagation actually solve?
Before this capability existed, a data agent built on Bedrock or SageMaker ran under its own IAM role, so Lake Formation saw the tool's credentials rather than the person behind the request. As AWS's security blog explains, that left teams with two bad options: restrict the tool's access so narrowly that it stops being useful, or grant it broad access and lose the ability to say who actually saw what.
Trusted identity propagation closes that gap by passing the signed-in user's identity context through the application layer and into the AWS services that enforce permissions. Lake Formation then evaluates access against the actual user's group membership and tag-based policies, not a generic application identity shared by every employee who happens to use the same chatbot. For anyone who has sat in a post-incident review trying to explain why a shared service account touched a sensitive table, this is the fix that should have existed years ago.
This matters more than it might sound, because data agents are exactly the kind of system that tends to get provisioned fast and governed slowly. A team ships a natural-language interface to the lakehouse, it works, usage grows, and only later does someone ask who can actually see payroll data through it. Identity propagation means that question has an answer baked into the architecture instead of bolted on after the fact.
Why identity, and not malware, is the cloud risk security leaders rank first
Identity has become the leading cloud risk because permission sprawl, not novel malware, is what actually causes breaches at scale. The State of Cloud and AI Security 2025 report from Tenable and the Cloud Security Alliance found that insecure identities have overtaken every other category as the top concern in cloud environments, based on a survey of more than a thousand IT and security professionals.
The breakdown of why is instructive. Coverage of the report found that the leading causes of breaches are failures in identity management, including excessive permissions at 31 percent, inconsistent access controls at 27 percent, and weak identity hygiene at 27 percent. That is a governance failure, not a technology gap, and it lines up with exactly the scenario trusted identity propagation targets: an agent or application that quietly accumulates broad, poorly scoped access because nobody wanted to build per-user permission logic by hand.
The same report found that complexity is compounding the problem. Organizations running hybrid and multi-cloud environments are managing identity across more boundaries than ever, which is one reason the full survey findings point to identity sprawl rather than any single exploit as the dominant exposure. If you work in cloud security, this is the backdrop that makes AWS's identity-aware agent work worth understanding in detail rather than treating it as a minor feature release.
Three identity failure patterns show up again and again in these reports, and they are worth naming because each one has a direct fix in the AWS identity model:
- Excessive permissions granted to a service role because scoping per-user access felt too slow to build.
- Inconsistent access controls across accounts, where the same data has different protection depending on which application touches it.
- Weak identity hygiene, including stale credentials and shared roles that nobody has reviewed since the project launched.
How does AWS audit what an AI agent actually accessed?
AWS answers this through CloudTrail's onBehalfOf field, which records the specific IAM Identity Center user whose identity was propagated through a request, not just the role the application assumed. According to AWS's own documentation on scaling fine-grained access control with Lake Formation, each access record includes the IAM Identity Center user UUID, the specific table queried, and the permission that allowed it, giving administrators a usable audit trail instead of a wall of identical service-role entries.
That detail changes what an incident responder can actually reconstruct after the fact. Instead of confirming that "the data agent" touched a table sometime in a four-hour window, you can confirm that a specific person's propagated identity was evaluated against Lake Formation's tag-based policies and either granted or denied access at query time. That is the difference between a plausible explanation and an auditable one, and it is the kind of control regulators and cyber insurance underwriters increasingly expect to see documented, not just described.
Getting this right in practice takes real configuration work. Connecting Lake Formation to IAM Identity Center, defining LF-Tag policies that map to business roles, and setting up trusted token issuers for whatever application sits in front of your data agent are not trivial exercises, and teams that skip steps tend to end up with the exact permission drift the identity sprawl reports describe. If your team is building this out, the Forge University resources page walks through how cloud identity and access control topics map across certification paths, which is a useful starting point before you commit to an architecture.
What changed in the AWS Security Specialty exam, and why it tracks this shift
AWS updated the Security Specialty exam to SCS-C03 in December 2025, and the change was not cosmetic. Analysis of the new exam guide found that AWS restructured the first domains and shifted weight toward identity management, signaling where the vendor believes modern cloud security work is actually decided. A separate breakdown of the update confirms that several domains were renamed and reweighted to better reflect current task objectives, with identity and access management carrying more scored content than in the prior version.
That is not a coincidence. The same year AWS shipped trusted identity propagation for data agents and the same year the CSA ranked identity as the top cloud risk, AWS also rewrote its flagship security certification to test identity and access management more heavily. If you hold or are pursuing the AWS Certified Security Specialty credential, this is the practical reason the exam changed shape, and it is also the reason the skill is worth more on a resume right now than it was two years ago. Hiring managers reviewing a candidate's AWS security background are increasingly going to ask whether that person understands trusted identity propagation, LF-Tag policies, and CloudTrail's identity fields, not just IAM basics.
What this means for how you design access control
The practical takeaway is to stop treating AI agents as a single identity and start treating them as a pass-through for whoever is actually asking the question. That means auditing every data agent, chatbot, or automation pipeline currently running under a shared service role and asking whether trusted identity propagation, or an equivalent identity-aware pattern, would close the gap between what the tool can technically reach and what each individual user is actually authorized to see.
It also means your incident response and access review processes need to account for the onBehalfOf field and similar identity context wherever your cloud provider exposes it, rather than stopping at the application layer. Teams that build this habit now will have a much easier time proving compliance and explaining incidents later, because the audit trail already has the answer built in.
If you want a study plan built around these exact identity and access control patterns, you can start training whenever you're ready. The underlying skill, mapping real user identity through layered cloud services instead of trusting a single application role, is quickly becoming the baseline expectation for anyone doing cloud security work, not a specialty niche.