Here’s an attack that would have sounded odd a few years ago. In 2024, Sysdig’s researchers caught a group breaking into AWS accounts. The attackers ignored customer data and went straight for the AI models.
They got in through an old Laravel bug, grabbed cloud credentials, and then poked around carefully to see what those keys could do on Amazon Bedrock. Sysdig called it LLMjacking. The plan was to run expensive models on someone else’s bill and resell the access. Sysdig estimated that a victim could pay more than $46,000 a day. With newer models like Claude 3 Opus, it later said the figure could pass $100,000.
Nobody broke Bedrock. Someone found a key that worked, attached to an identity with far more access than it needed.
I keep coming back to that, because it’s the whole IAM story with a new twist. Most lists of AWS IAM best practices say the same few things: use roles, grant the minimum, keep credentials short-lived. That advice hasn’t changed. What’s changed is the number of things that now need an identity (agents, copilots, model endpoints) and how quickly a sloppy one turns into a bill.
Why Is IAM Getting Harder in the AI Era?
Try counting the non-human identities in your AWS account. Lambda functions. CI pipelines. Containers. The monitoring tool someone wired up in 2022 and never mentioned again. Then add the agents.
CyberArk’s 2025 research found 82 machine identities for every human, and expects AI to create more new privileged identities than anything else. That number should bother people more than it seems to. An agent isn’t a chatbot that answers a question and goes quiet. It reasons through steps, calls tools and writes to systems. Every one of those actions runs on somebody’s permissions, often whichever credentials were handiest during the demo.
Old IAM risk | What AI does to it | Fix |
| Long-lived access keys | Agents get a static key “just for testing,” and the key outlives the test | Roles and temporary credentials |
| Broad policies | An agent with full service access can be steered into misusing all of it | One tightly scoped role per agent |
| Hardcoded secrets | AI coding assistants help paste keys straight into code | Secret scanning and credential providers |
| Nobody watching usage | Stolen keys get spent on pricey model calls | Alerts on Bedrock activity and spend |
| Privilege creep | Pipelines create roles faster than humans review them | Permission boundaries |
Should AI Agents Use IAM Roles or IAM Users?
Roles. I can’t think of a good argument for users here.
An IAM user’s access key lives until someone deletes it, and in practice nobody does. Roles hand out temporary credentials through AWS Security Token Service. A session can be as short as 15 minutes or as long as 12 hours if you configure it that way, and the default is one hour. When it expires, a leaked credential is useless.
EC2, Lambda, and ECS already assume roles on their own, so there’s no key for anyone to copy. Agents should work the same way, and AWS now builds for that. Amazon Bedrock AgentCore Identity gives each agent its own workload identity, so the agent reaches AWS through IAM roles and outside tools through OAuth instead of borrowing a person’s login. Its credentials sit in a token vault, not in prompts, environment variables, or source files.
Not on AgentCore? The rule still holds. One agent, one role, scoped to that agent’s job. Sharing a single role across five agents because it saved ten minutes is how incident reports start.
People should skip IAM users as well. Put them on IAM Identity Center with federated sign-in, so nobody keeps a permanent key pair on a laptop.
How Do You Apply Least Privilege to AI Workloads?
Everyone agrees with least privilege. Then a deadline arrives, someone attaches AmazonBedrockFullAccess, or AdministratorAccess on a bad day, writes “tighten later” in a ticket, and later never comes.
With agents, that shortcut gets expensive. A human admin still has to choose to do something reckless. An agent with admin rights can be talked into it by a poisoned web page, a malicious PDF, or a support ticket it was asked to summarize. Prompt injection turns over-broad permissions into a real attack path.
The fix takes a bit of patience. Start by writing down what the agent actually touches: which APIs, which buckets, which tables. Grant exactly that, and nothing “just in case.” Let it run for a few weeks, then have IAM Access Analyzer generate a policy from its CloudTrail history, which shows what it really used. And split reading from writing. An agent that summarizes reports in S3 has no business holding s3:DeleteObject.
One more thing, since it comes up constantly. Yes, AI tools will write IAM policies for you, and the first drafts are often decent. They’re also confidently wrong in one predictable direction: too much access. Read a generated policy line by line, the way you’d review code from a new hire.
How Do You Get Rid of Long-Lived Access Keys?
Most cloud breach stories start with a static key that ended up in the wrong place. A .env file. A CI variable. A Slack thread. An old backup nobody remembered.
GitGuardian’s figures are grim. It found 23.8 million new hardcoded secrets in public GitHub repos in 2024, up 25% on the year before. Seventy percent of the valid secrets it spotted back in 2022 were still working. And the AI angle shows up here too: repos with GitHub Copilot enabled leaked secrets at a 40% higher rate. In private repositories, AWS IAM keys made up 8% of everything found.
So what helps? Move every workload that can assume a role onto one. Federate people through IAM Identity Center. Turn on secret scanning in repos and pre-commit hooks, especially wherever AI coding assistants are in use. Set an alert for any key past a certain age, and once a quarter delete the keys nobody has touched in 90 days. If no one complains, they weren’t needed.
Monitoring helps, and so does patching, but neither fixes the root problem with a static key, which is that it never expires.
What Do Permission Boundaries Do for Automated Systems?
A permission boundary sets a ceiling. Whatever policies get attached to a role later, it can never go above that line.
That used to matter mostly in large companies, where deployment pipelines created roles all day. Now agent frameworks create them too, and no security team can read every one. With a boundary on what a team’s automation can grant, a careless policy or a hijacked pipeline still hits the ceiling.
I’d put boundaries on anything that can create roles, and on every role an agent runs under. It’s one of the few controls that still works when the individual policies underneath are a mess.
How Should You Monitor IAM and AI Activity?
Configs drift. A role that was tight in January has three extra policies by June, each added for a reason nobody can remember by October.
CloudTrail logs every API call and who made it, so everything builds on that. Beyond the usual checks (unused permissions, strange login locations, new keys appearing), watch for AI-specific signals:
- Bedrock calls from a role that has never used Bedrock before
- A sudden jump in model invocations or token use
- Any change to which foundation models are enabled in the account
- Someone checking or switching off logging, which LLM-jacking crews were seen doing to hide
Set up billing alerts too. Sometimes a spike in model spend is the first warning anyone gets. And if your company spent the past year telling staff to use AI for everything, you’ve probably got some AI sprawl nobody has mapped, which means credentials sitting in tools nobody tracks.
Quarterly access reviews close the loop. Team leads confirm that each role still needs what it has. Anything nobody will vouch for gets removed.
FAQs
Q. What is LLMjacking?
Using stolen cloud credentials to run hosted AI models on the victim’s bill. Sysdig named it in 2024 after watching attackers abuse AWS keys to reach Bedrock and other LLM services.
Q. Do AI agents need their own IAM roles?
Yes. Give each one its own narrow role, so you can audit it, restrict it or revoke it without breaking anything else.
Q. Can I let AI write my IAM policies?
For a first draft, sure. Check every action and resource before anything goes live, because generated policies tend to grant more than needed.
The Bottom Line
None of this is new. Roles over users, least privilege, short-lived credentials and boundaries were good advice long before anyone built an agent. AI just raises the price of ignoring them. A forgotten key used to risk a data leak. Now it can also produce a five-figure model bill overnight, run up by someone you’ll never find. Get the basics right, then treat every agent like a new admin with a short leash.
Related: 10 Best AI Computer Vision Development Companies for Manufacturing Operations in 2026
