AWS Public Sector Blog
Why the location of your AI agent is a security decision
US Federal agencies face dual mandates: adopt AI rapidly and secure it at every layer. Executive Order 14179 directs accelerated AI adoption. OMB M-25-21 requires agencies to assign Chief AI officers, CFO Act agencies to publish AI strategies within 180 days, and delegate accountability for AI risk acceptance to appropriate officials. OMB M-26-04 directs agencies to apply unbiased AI principles when procuring large language models, including requirements for truthfulness and transparency. The March 2026 National AI Legislative Framework outlines the administration’s priorities for proposed Congressional AI legislation, including innovation acceleration and responsible AI governance.
The through line across all four directives: innovate fast, but not recklessly. Teams evaluating AI agents (autonomous software that can reason, plan, and act) must resolve how to authorize such code within regulated information systems.
An AI agent is code running in a compute environment, calling APIs. On a user’s laptop, it inherits the user’s full permissions (files, credentials, network access) as well as any established isolation boundaries. On Amazon Web Services (AWS), it operates inside a scoped compute environment with an AWS Identity and Access Management (IAM) execution role, network segmentation, and defense-in-depth security meeting FISMA, FedRAMP, and DoD CCSRG standards. Those controls are deterministic. They do not change based on what the model thinks.
The shift in perspective—from asking “How do we trust the AI?” to “Are we running it where our controls already apply?”—helps teams move from deliberation to scoped agent pilots. This post unpacks that reasoning.
Treat your agent as code
An AI agent is an application. It runs in AWS Lambda, Amazon Elastic Container Service (Amazon ECS), or Amazon Elastic Kubernetes Service (Amazon EKS). It has an IAM execution role. It sits inside an Amazon Virtual Private Cloud (Amazon VPC). It writes logs to AWS CloudTrail.
The foundation model (FM), whether Amazon Nova 2 Lite or Amazon Nova 2 Sonic on Amazon Bedrock, is a stateless API call. It returns text. It can’t execute code, overwrite files, or reach into your infrastructure. Your application code in your compute environment parses that response and decides whether to act on it. When you add agent capabilities—action groups, tool use, code interpretation—it is your execution layer, governed by your IAM roles and network controls, that carries out those actions, not the model. Amazon Bedrock is the reasoning layer. Your compute layer is the execution layer. They are separate, and the execution layer is fully under your control.
This means the security controls you already enforce on your workloads (IAM least privilege, VPC isolation, security groups, encryption, logging) apply to your AI agent. You don’t start from zero. You start from the security posture you have already built.dd
What you already have vs. what you add
The following table shows how existing cloud security controls map to AI agent workloads, and where AI-specific controls extend them. The left column represents standards and mechanisms that predate AI. The right column represents the targeted additions.
| Security Concern | Controls You Already Use | AI-Specific Additions |
|---|---|---|
| Identity and authorization | IAM execution roles, AWS Security Token Service (AWS STS) temporary credentials, Amazon Cognito authentication, JWT-based identity propagation | Propagate user identity through agent interactions using standard OAuth/JWT flows so agent actions trace back to the human who initiated it. |
| Network isolation | VPC segmentation, security groups, AWS Network Firewall, AWS WAF rate limiting, AWS Shield DDoS protection | Rate limiting for AI endpoints to control both abuse and cost. |
| Data protection | AWS Key Management Service (AWS KMS) encryption at rest and in transit, AWS Secrets Manager credential rotation, AWS PrivateLink for inter-service traffic | Amazon Bedrock Guardrails for real-time personally identifiable information (PII) detection and redaction on inputs and outputs. Amazon Macie for scanning data stores. |
| Application protection | Input validation, AWS Organizations service control policies, OAuth authorization flows | Amazon Bedrock Guardrails for prompt injection defense and content filtering. Human-in-the-loop approval hooks for agent actions. Resource control policies scoped to AI capabilities. |
| Threat detection and audit | CloudTrail API logging, Amazon CloudWatch monitoring, incident response procedures | Amazon GuardDuty AI-specific threat detection (suspicious model invocations, unusual guardrail removal, disabled logging). |
Figure 1. Existing cloud security controls (left) map directly to AI agent workloads. AI-specific additions (right) extend, not replace, the controls public sector organizations already operate.
The pattern is consistent: the foundation is the same. IAM, Amazon VPC, AWS KMS, CloudTrail, and JWT have operated across millions of workloads for years. AI agents inherit all of them. The additions are targeted: guardrails for content filtering, identity propagation for agent-to-human traceability, and threat detection tuned to AI-specific signals.
Scope the controls to the workload
The compute environment stays the same regardless of how much autonomy you give the agent. What changes is how many AI-specific controls you layer on top. The Agentic AI Security Scoping Matrix, referenced by organizations including OWASP and the Coalition for Secure AI (CoSAI), helps you decide how much to apply:
- Scope 1 – The AI responds but takes no action. Your existing compute, IAM, and network controls are sufficient.
- Scope 2 – The agent suggests actions, and a human approves each one. Add human-in-the-loop hooks and tighter IAM permission boundaries on the execution role.
- Scope 3 – Automated agentic actions with monitoring. Layer in Amazon Bedrock Guardrails, GuardDuty AI threat detection, and identity propagation for full traceability.
- Scope 4 – Fully autonomous agent action. Apply the complete control set from the preceding table, with continuous evaluation and AI-specific incident response procedures.
Start at Scope 2, the same incremental approach you would take when granting a new application additional permissions. The IAM role, VPC, and encryption do not change between scopes. You start restrictive and expand based on evidence.
For AWS GovCloud (US) customers, this compute-level framing is especially relevant. Managed agent orchestration services, including Amazon Bedrock AgentCore, are now available in AWS GovCloud (US-West). But the underlying pattern doesn’t depend on them. Agent runtimes deploy on Lambda, Amazon ECS, or Amazon EKS, the same compute services already authorized in your environment. The reasoning layer is an API call to Amazon Bedrock. Identity propagation uses standard OAuth/JWT flows. Encryption uses AWS KMS. Logging uses CloudTrail. The controls in the preceding table are available in AWS GovCloud (US) at the time of writing because they are compute and infrastructure controls, not AI-specific services. AWS was the first major cloud provider to achieve ISO 42001 certification, the international standard for AI management systems, providing an independently audited foundation for AI governance.
Getting started
Map your agent deployments against the scoping matrix, verify your existing controls extend to AI workloads, and add targeted AI-specific mechanisms.
- Scope your use cases. Map planned agent deployments against the Agentic AI Security Scoping Matrix. Start at Scope 2.
- Verify your existing controls extend to AI. Confirm that IAM least privilege, VPC isolation, encryption, and CloudTrail logging cover your agent compute environments.
- Add AI-specific controls. Deploy Amazon Bedrock Guardrails for content filtering and PII detection. Configure GuardDuty AI threat detection. Implement human-in-the-loop approval for agent actions.
- Design your agent threat model. Work with your security team—and your AWS Technical Account Manager and Solutions Architect—to map agent-specific threats against your existing control framework.
The security of an AI agent is not about trusting the model. It is about running it where your controls already work, and adding the targeted set of AI-specific mechanisms on top. The standards that protect your workloads today are the same standards that protect your agents tomorrow.
To learn more, review the AWS Well-Architected Generative AI Lens, Security Pillar and the infrastructure security guidance for agentic AI on AWS.