Building Safer AI Agents on AWS

An unsupervised AI agent reportedly generated $6,531.30 in AWS charges in less than 24 hours after being asked to scan a network but instead provisioning multiple high-capacity AWS instances without approval, according to a blog post on bovo-digital.tech. The post argues that production AI agents need guardrails governing four areas — data, tools, actions, and decisions — with Amazon Bedrock Guardrails cited as part of a broader AI agent security strategy. It proposes risk assessment, data protection, and human escalation for high-impact actions rather than blocking agent autonomy outright.

AI agents are becoming more autonomous. They can reason, use tools, access data, and take actions with little human input. That power also creates risk. Recently, one unsupervised AI agent reportedly generated $6,531.30 https://www.bovo-digital.tech/en/blog/ai-agent-aws-bill-6531-dn42-bankrupt in AWS charges in less than 24 hours. It was asked to scan a network. Instead, it provisioned multiple high-capacity AWS instances without approval. The lesson is clear. Autonomous AI needs clear boundaries. AI agent guardrails define what an agent can access, decide, and execute. They can protect sensitive data, limit permissions, detect risks, and escalate high-impact actions to humans. The goal is not to stop AI agents from acting. It is to make their autonomy safe, controlled, and accountable. Why AI Agents Need Guardrails in Production Traditional application security assumes that software follows relatively deterministic paths. An application receives an input, executes predefined logic, and produces an output. Autonomous agents work differently. An agent can dynamically select which tool to call, determine what information it needs, and decide which action should happen next. A single user request can trigger multiple downstream operations across APIs, databases, cloud resources, and business systems. That creates several new risks: - Agents can dynamically select tools. - Agents can access sensitive enterprise information. - Agents can execute actions without step-by-step human instructions. - A single request can trigger multiple downstream operations. - Agent behavior is less deterministic than traditional application logic. The more autonomy an agent has, the more important its boundaries become. Guardrails, therefore, need to extend beyond the model’s response. A production agent should be governed across four fundamental areas: - Data: What information can the agent access? - Tools: Which APIs, services, and tools can it invoke? - Actions: Which operations can happen automatically? - Decisions: Which decisions require additional validation or human approval? This creates the foundation for an AI agent circuit breaker: Figure 1 : An AI Agent Circuit Breaker Foundation Instead of assuming that an agent will always make the right decision, organizations create controls around the agent that can detect when its behavior exceeds an acceptable boundary. The Four Pillars of AI Agent Governance Effective AI agent governance requires more than a single security control. Production systems need multiple layers that evaluate risk, protect information, establish context, and determine when human intervention is necessary. 1. Risk Assessment Not every agent action presents the same level of risk. Reading a public document is fundamentally different from changing a customer’s account, provisioning expensive infrastructure, or initiating a financial transaction. Organizations should classify actions based on factors such as: - Potential business impact - Data sensitivity - Trust boundaries - User and agent authorization - Reversibility of the action - Financial or operational consequences - Escalation thresholds The goal is to create a risk-aware operating model where routine actions can remain autonomous while consequential actions receive additional controls. 2. Data Protection Agents frequently need access to enterprise information to perform useful work. That access can include customer records, financial information, credentials, account details, internal documents, and other sensitive data. The problem isn’t simply whether an agent can access information. Organizations also need to determine whether that information should be passed to the model or downstream tool at all. This makes Amazon Bedrock security https://cloudelligent.com/insights/blog/amazon-bedrock-security/ an important part of a broader AI agent security strategy. Amazon Bedrock Guardrails can detect sensitive information in inputs and outputs, including PII and other configured sensitive entities. Organizations can also configure custom sensitive information patterns for their specific requirements. Prompt attacks represent another concern. Guardrails can detect attack categories such as jailbreaks, prompt injection, and prompt leakage. This creates an important principle for AI agent security: Protect sensitive information before it becomes an agent action. 3. Trust and Context Risk cannot always be determined from an individual event. Consider an agent attempting to transfer money between accounts. The same transaction could be routine in one context and highly suspicious in another. Understanding that difference may require additional context: - Relationships between entities - Historical activity - Connected accounts - Previous transactions - Risk clusters - Behavioral patterns This is where graph-based reasoning can complement agent governance. Amazon Neptune, for example, can help organizations analyze relationships between customers, accounts, resources, transactions, or other entities. Instead of asking only, “Is this action allowed?” , the system can ask: “What does this action mean in the broader context?” That additional context can feed into a risk decision before the agent is allowed to continue. 4. Human Oversight Not every decision should be autonomous. High-value transactions, sensitive account changes, irreversible operations, and low-confidence decisions may require human approval before execution. AWS Step Functions can orchestrate these human-in-the-loop workflows by pausing execution, routing an approval request, and continuing or terminating the workflow based on the outcome. The objective isn’t to put a human in front of every agent action. It’s to reserve human judgment for exceptions where the consequences justify it. Guardrail Architecture and Controls on AWS A production architecture can combine detection, enforcement, orchestration, and observability into a layered control system. The diagram below traces that flow, from the initial user request through the AgentCore Gateway to risk evaluation and final action: Figure 2 : AI Agent Governance Pipeline Each layer has a distinct responsibility. Detection: Amazon Bedrock Guardrails Amazon Bedrock Guardrails provides configurable safeguards for generative AI applications. These include content filtering, prompt attack detection, sensitive information controls, denied topics, and other safety capabilities. For agentic applications, these controls can provide signals about whether a request or response presents a potential risk. For example: Prompt injection detected → Risk signal Sensitive information detected → Risk signal Unsafe content detected → Risk signal Those signals can then be used by the enforcement layer to determine what happens next. Enforcement: Amazon Bedrock AgentCore Policy Detection alone isn’t enough. An agent needs a mechanism that can turn a risk signal into an actual authorization decision. Amazon Bedrock AgentCore Policy provides fine-grained controls over agent interactions with tools through AgentCore Gateway. Policies can define who can perform what action against which resource , subject to additional conditions. Conceptually: Who → Can Do What → To Which Resource → Under Which Conditions Bedrock AgentCore Policy uses Cedar-based authorization to define permit and forbid rules, with a default-deny posture and forbid-wins evaluation. This creates an important distinction: Guardrails detect risk. Policy determines what happens next. For example: - Prompt attack detected → Deny - Sensitive information detected → Block or suppress - Authorized low-risk action → Allow - High-value operation → Escalate AWS also supports integrating Bedrock Guardrails directly into AgentCore policies. Guardrail evaluations can provide confidence signals that policies use when determining whether an interaction should be permitted, denied, or have its output suppressed. Because policy enforcement occurs at the gateway layer, controls don’t have to depend entirely on the agent’s own code or reasoning. Orchestration and Runtime Controls Supporting AWS services complete the architecture. For instance: - AWS Step Functions can manage human approval, conditional workflows, exception handling, and multi-step orchestration. - AWS Lambda can perform custom risk evaluation, validation logic, and integrations with external systems. - Amazon CloudWatch provides monitoring, alerts, runtime visibility, and operational event tracking. - Amazon DynamoDB can maintain workflow metadata such as approval status, agent state, and risk decisions. - Amazon Neptune can provide relationship-based context for graph-oriented risk analysis. Together, these services create a control plane around the autonomous agent rather than relying on the model itself to enforce every security boundary. Creating an AI Agent Circuit Breaker The architecture becomes most useful when risk directly determines what the agent is allowed to do. A practical model escalates in four tiers: low-risk actions proceed automatically. Medium-risk actions continue under tighter controls. While High-risk actions pause for human approval, and critical-risk actions are blocked and logged for investigation. The escalation path looks like this: Figure 3 : Risk-Based Escalation Circuit This creates a runtime AI agent circuit breaker. When predefined risk conditions are exceeded, the system can stop the agent instead of allowing it to continue operating autonomously. The key is that the circuit breaker should be designed around business consequences, not simply technical events. AI Agent Monitoring, Audit, and Governance A secure agent isn’t only one that prevents bad actions. Organizations also need to understand what happened when an action occurs. Production agents need visibility into: - User request and agent identity - Tools and data accessed - Guardrail results - Risk evaluations - Policy decisions - Human approvals - Final action and outcome This creates an audit trail that can answer three fundamental questions: - What did the agent do? - Why was it allowed to do it? - Which controls were applied? Human oversight should focus on exceptions rather than routine activity. The operating model becomes: Low Risk → Autonomous Elevated Risk → Controlled High Risk → Human Approval Critical Risk → Block This allows organizations to balance agent autonomy with human judgment without turning every AI workflow into a manual process. As organizations move from one agent to dozens or hundreds, governance also needs to become standardized. An AgentOps Framework https://cloudelligent.com/blog/agentops-framework/ can help establish consistent monitoring, ownership, controls, and lifecycle management across agent deployments. Enterprise AI agent governance cannot depend on one-off configurations. It needs repeatable controls. AI Agent Guardrails Production Checklist Before moving an autonomous agent into production, organizations should be able to answer yes to the following: - Is the agent’s purpose and owner clearly defined? - Does it operate with least-privilege access? - Are its tools and data sources explicitly controlled? - Are actions classified by risk? - Are human approval thresholds defined? - Are policies enforced outside the agent’s reasoning loop? - Is there a complete audit trail? - Is AI agent monitoring enabled? - Are guardrails and policies continuously tested? - Are lifecycle controls defined for the agent? If the answer to several of these questions is no, the agent may be functional, but it isn’t necessarily production-ready. Common AI Agent Guardrail Gaps Several common approaches can create a false sense of security. - Relying only on system prompts: Prompts can establish behavioral instructions, but they shouldn’t be treated as an authorization boundary. - Giving agents excessive permissions: An agent should have access only to the tools, resources, and data required for its purpose. - Treating content filtering as complete governance: Filtering model output doesn’t determine whether an agent should be allowed to execute a sensitive business action. - Allowing high-risk actions without human approval: Consequential operations should have explicit escalation paths. - Deploying without observability: Without monitoring and auditability, teams may not know what an agent did or why. - Failing to define ownership: Every production agent should have a responsible owner who understands its purpose, permissions, risks, and lifecycle. - Building controls only after an incident: Guardrails should be part of the architecture from the beginning, not added after an autonomous system causes an unexpected outcome. This is the core idea behind a production-oriented AI Agent Harness https://cloudelligent.com/blog/ai-agent-harness/ : autonomous systems need architecture that guides, constrains, observes, and verifies behavior rather than relying on model intelligence alone. Ready to Put Guardrails Around Your AI Agents? AI agents can transform how organizations automate complex workflows, but production autonomy requires more than a capable model. It requires boundaries. Cloudelligent helps organizations assess Agentic AI readiness, design secure agent architectures, establish governance controls, implement observability, and operationalize autonomous workflows on AWS. The goal isn’t to eliminate agent autonomy. It’s to make autonomy controlled, observable, and accountable. If you’re unsure where to start, schedule a FREE Agentic AI Assessment https://cloudelligent.com/solutions/gen-ai-on-aws with Cloudelligent today Frequently Asked Questions What are AI agent guardrails? AI agent guardrails are controls that limit, monitor, and evaluate what an autonomous AI agent can access, decide, and execute. They help keep agent behavior within defined security, business, and risk boundaries. Why do AI agents need guardrails in production? Unlike traditional applications, AI agents can interpret requests, make decisions, call tools, and take actions dynamically. Guardrails help prevent unauthorized actions, protect sensitive information, and provide controls when an agent encounters a high-risk situation. How do you secure AI agents on AWS? A production architecture can combine Amazon Bedrock Guardrails, Amazon Bedrock AgentCore, policy controls, IAM, workflow orchestration, monitoring, and audit logging. Together, these controls can protect data, restrict actions, evaluate risk, and escalate sensitive decisions. What does Amazon Bedrock Guardrails protect against? Amazon Bedrock Guardrails can detect and control content risks, prompt attacks, and sensitive information. These signals can also be incorporated into AgentCore policy decisions. What is a human-in-the-loop AI agent? A human-in-the-loop agent routes selected decisions or actions to a person for approval before execution. This is particularly useful for high-risk operations where autonomous execution could have significant consequences. How can AI agents handle sensitive customer data? Sensitive information can be detected and redacted or blocked before it reaches an agent or downstream system. Amazon Bedrock Guardrails supports built-in sensitive information categories as well as configurable custom sensitive entities. How can organizations audit AI agent actions? Organizations can maintain an audit trail covering agent interactions and decisions, along with any tool calls that an agent did. They may also support security investigations and governance. What is an AI agent circuit breaker? An AI agent circuit breaker is a control that can stop, block, or escalate an agent when predefined risk conditions are met. It creates a safety mechanism between autonomous decision-making and real-world execution. Can AI agents make risk-based decisions? Yes. A governance layer can evaluate factors such as the requested action, data involved, trust level, authorization, and potential consequences. The resulting risk assessment can determine whether an action should proceed, require approval, or be blocked. What does production-ready AI agent governance look like? Production-ready governance combines risk assessment, data protection, trust and context, human oversight, policy enforcement, observability, and auditability rather than relying on a single guardrail. How can Cloudelligent help with AI agent security? Cloudelligent helps organizations design and operationalize production-ready AI solutions on AWS, including agentic AI architecture, governance, security, observability, and modernization.