Most agent security guidance is about the agent. What about the cloud account it lands in?
An AI agent is a workload that can act. It reads data, calls tools, and makes changes, and it does so without a person approving each step. The guidance reaching security teams is mostly about the agent itself: how to give it an identity, how to narrow its tools, how to keep secrets out of its context, when to put a human in the loop. That work matters, and it is the agent team's job. Most of it lives in the harness, the code or service that runs the model's tool loop and holds its credentials.
The cloud security team has a different job. An agent that is designed well still runs in a cloud account, and the roles, policies, and network configured there are what actually enforce the design. Deny-by-default egress is a design goal for the agent; in your account it is a VPC with no route out. Least privilege is a design goal; in your account it is the policy on the agent's role. Are your accounts ready to host something that acts on its own?
1. Do you know where AI runs in your accounts?
Start with an inventory: model endpoints, agent harnesses, MCP servers (the tool servers agents call over the Model Context Protocol), and the Lambda function someone wired to an LLM API in March all count. On AWS the reliable source is CloudTrail: query for principals calling bedrock:Invoke*, which covers models and agents alike. AWS Config and Resource Explorer fill in the Bedrock and SageMaker resource types they support, which is not all of them, and VPC flow logs or firewall logs show traffic to third-party model APIs from accounts that are not supposed to be talking to them. Shadow AI in a cloud account looks a lot like shadow IT did, except that the thing you did not know about runs on its own, with whatever permissions it was handed, and nobody is sitting at the keyboard.
2. Does every agent have its own identity, with no static or shared credentials?
Every agent gets its own IAM role, assumed through STS with credentials that expire in hours rather than months. No long-lived access keys, no shared service account that three agents and a cron job all use, no API key pasted into an environment variable and forgotten. Keys for third-party model APIs live in Secrets Manager and are fetched by the role at runtime. Static keys and shared service-account passwords are not a legitimate baseline anymore. If CloudTrail cannot tell you which agent performed an action from the role it assumed, you do not have an identity for it; you have a shared password.
3. Is each agent's access scoped to least agency, not just least privilege?
Least privilege asks what a principal can touch. Least agency, that idea extended to agentic systems, asks the same question of every agent and sub-agent in the system, and expects each one to get a policy sized to its own job. IAM cannot see the harness and it cannot see the agent's tools; it only sees the AWS API calls those tools make. On AWS, least agency means a role policy narrowed to the actions and resources each agent's tools need, with a permission boundary or service control policy (SCP) above it as a ceiling the agent cannot talk its way past. Data access follows the same pattern: tag the data by classification and use tag conditions (aws:ResourceTag for tables and buckets, s3:ExistingObjectTag for objects) so an agent can only read what it is cleared for. Where this goes wrong is delegation: a coordinating agent hands work to a sub-agent and passes its own credentials along unchanged. Each sub-agent assumes its own, narrower role, and keeping the sub-agent's permissions out of the coordinator's role is what makes the inherited credentials useless for the delegated job.
4. Is agent network egress deny-by-default?
Agents run in private subnets. They reach AWS services through VPC endpoints whose policies limit which resources are reachable over that path, and they reach external model and tool APIs only through a proxy or Network Firewall rule that names the allowed destinations. A test worth applying to every control on this list: does it make the attack impossible, or merely tedious? Rate limits and port restrictions are tedious. A network path that does not exist is impossible. Detection still matters, but on its own it means you find out about the exfiltration after it happened. Egress is where prevention is cheapest.
5. Is a guardrail enforced on every model call?
Every document, web page, ticket, email, and tool result an agent reads is a potential set of instructions, because the model does not reliably distinguish data from commands, and a cloud security team cannot fix that at the model layer. How the harness handles untrusted content is the agent team's call. What the cloud team can do is put Bedrock Guardrails in front of the model to screen prompts on the way in and filter the model's responses on the way out. By default the caller decides whether a guardrail is attached, so the control the cloud team owns is the bedrock:GuardrailIdentifier condition on the agent's role or in an SCP, which denies any invocation that does not carry the named guardrail. That makes it the one prompt injection control enforced by an IAM policy rather than by the agent's code, and it should be on.
6. Can you trace an action back to the prompt that caused it?
Every log is replicated to one bucket with Object Lock, in an account the agent's role cannot reach: Bedrock model invocation logging, the CloudTrail record of the AWS actions that result, and whatever the harness logs about its tool calls. The links are the role session name, which identifies the agent in CloudTrail, and a request ID the harness carries from prompt to tool call. The first can be required with an sts:RoleSessionName condition in the role's trust policy; the second is something to ask the agent team for. From there an investigator can start at an S3 delete and end at the prompt behind it. An agent that can read or write its own audit trail has a blast radius that includes the evidence.
7. Is agent behavior baselined and monitored?
GuardDuty is on in every account and region where agents run, Security Hub findings for the agent roles are routed to a queue a person actually reads, and alerts cover the things that distinguish a misbehaving agent from a working one. GuardDuty baselines API activity and catches unusual call sequences and privilege grants on its own; new egress destinations and invocation volume spikes are CloudWatch alarms the cloud team writes. Turning these on is the easy part. Whether anyone is responding shows up in two numbers: dwell time, how long an anomaly sits before a human knows about it, and coverage, what fraction of alerts get investigated. If you cannot state both for your agent workloads, monitoring is a dashboard rather than a control.
8. Are high-impact actions gated by a human?
There is a short list of things an agent should be able to propose but never execute on its own: IAM changes, deletes, messages to anyone outside the boundary, payments, anything irreversible. Write the list down. Then enforce it in IAM: the agent's role does not hold those permissions at all, and the actions live behind a separate role that only the approval workflow can assume, whether that is Step Functions waiting on a callback or a separate service the agent team runs. It cannot be the harness itself: a harness that can assume the privileged role is an agent that can. The harness asking a human is a courtesy; the agent's role lacking the permission is the control. The approval is bound to exactly what it authorized, and logged, so an approval a compromised agent captured cannot be replayed against a different action.
9. Is execution sandboxed, and is the supply chain controlled?
Agent code and any interpreter it can call run in isolated compute, such as a Fargate task or a Lambda function, with no host to persist on and nothing kept between jobs. The sandbox gets the same egress rules and a role no wider than the agent's own, and none at all if the code inside does not need AWS. The cloud security team does not control what the agent team pins in their build, but it does control what is available to pull. Images come from a registry you run, whether ECR or an internal artifact store, and the execution role plus the egress rules from item four make that the only place they can come from. Inspector is on for ECR and for Lambda, so images are scanned, and rescanned as new vulnerabilities are published. MCP servers deserve particular suspicion here: they are new, plentiful, most of them have never been reviewed by anyone but their author, and whatever one of them returns, the agent will act on. Adding one to a production agent should get the review a new dependency would.
10. Does someone own each agent, and do they know what to do when it misbehaves?
Every production agent has a named owner, a documented scope, and a review it passed before it was allowed to act. When it goes wrong, and one will, the owner has a runbook, and item two is what makes it short. Because the agent has its own role, revoking it is a deny-all policy on that one role, with an aws:TokenIssueTime condition to kill the sessions already in flight, and nothing else in the account is affected. The agent's memory, whether a DynamoDB table, an S3 prefix, or a vector index, is a known resource with a backup and a documented way to wipe it. A poisoned memory is the one part of the incident that outlives the credentials. The team has run a tabletop exercise against this runbook, and has run it with more than one agent misbehaving at once.
What a no means
A team that answers no to most of these is not behind; it is where nearly everyone is. Most of the controls above are not new. IAM roles, permission boundaries, VPC endpoints, and GuardDuty have existed for years, and the guidance on how agents should behave is now written down. What is missing is the deliberate act of applying the first to the second, for a workload that behaves differently from the ones your environment was built for. Three steps make a useful start:
- Run the inventory. Answer item one properly, including the things nobody told you about, before you spend time on the rest. You will find something.
- Start with the controls that make the attack impossible. Identity, scoping, and egress (items two through four) turn most agent failure modes into non-events, and they are enforced by IAM and the VPC.
- Name the owner. Item ten costs nothing to start and determines whether the other nine ever get maintained.
One more thing, which is not a control: the cloud security engineers who inherit all this need time to learn how agents fail, which is a different skill from knowing how servers fail. It is the part that is easiest to defer and most expensive to skip.
Know what is running, limit what it can do, and name who answers for it. Do that and an agent landing in your cloud is a workload, not an event.
Further reading
- AWS, Well-Architected Framework: Generative AI Lens
- Cloud Security Alliance, AI Controls Matrix v1.1
- Anthropic, Zero Trust for AI Agents
- OWASP, Top 10 for Agentic Applications for 2026
About the Author
Brian is a Principal Engineer at Cloud Security Partners. He has dedicated his 20-year career to cybersecurity, gaining expertise across offensive and defensive security. He began with a focus on application and penetration testing before transitioning to securing cloud infrastructures for both startups and enterprises. In addition to his security expertise, Brian has recently worked as a software engineer, developing enterprise cloud security solutions, leading engineering teams, managing people, shaping product direction, and maintaining strong customer relationships. His broad experience allows him to bridge the gap between security, engineering, and business needs.Outside of work, Brian enjoys spending time with his family, hiking, and playing board games.
Stay in the loop.
Subscribe for the latest in AI, Security, Cloud, and more—straight to your inbox.
