Securing AI Infrastructure in AWS: A Preventive Guardrails Approach for the Agentic Cloud

AI infrastructure is no longer limited to chat interfaces or isolated model experiments. Across cloud platforms, it is becoming an operational layer that connects models, agents, tools, identities, data, and services.
That shift creates a new security problem. An LLM by itself can generate a risky answer. But an AI agent connected to APIs, internal tools, functions, data stores, and production workflows can act on that answer. It can retrieve data, invoke tools, trigger automations, and operate through identities that may have real permissions.
For cloud security teams, this changes the question from:
“How do we monitor the model’s activity?”
to:
“How do we prevent the AI system from taking unsafe actions in our production?”
This is the foundation of securing AI operations across all cloud platforms.
Model-level controls are important, but they are not enough. Prompt filters, content policies, and response validation can reduce unsafe outputs, but they do not define what an agent is technically allowed to do. That enforcement must happen in the control plane, through native controls such as IAM, LLM Guardrails, platform policies, network path restrictions, and agent-specific policies.
This is where Blast’s approach to cloud security becomes especially relevant. Blast helps organizations move from reactive cloud risk management to preemptive cloud defense by turning native cloud controls into preventive guardrails that can be simulated, enforced, monitored, and managed with controlled exceptions.
For AI infrastructure, the goal is simple:
Let AI systems reason, but make sure they don’t make irreversible or unallowed actions.

How AI Agents Change the Cloud Security Boundary

When AI workloads, such as large language models (LLMs), are hosted in platforms like Amazon Bedrock, the architecture might seem straightforward at first:

Application → Amazon Bedrock → Foundation Model → Response

In production, the architecture is usually more complex. A real AWS-based AI system may include:

• Amazon Bedrock foundation model access
• Bedrock Guardrails for prompt, response, sensitive data, and reasoning controls
• Bedrock Agents or AgentCore runtimes
• AgentCore Gateway for tool access and LLM routing
• Lambda functions, APIs, or MCP servers exposed as tools
• S3, DynamoDB, RDS, KMS, IAM, and other AWS services accessed by the agent
• IAM roles used by the application, agent, gateway, and downstream tools
• VPC endpoints and private connectivity paths
• CloudTrail, CloudWatch, and service logs for audit and investigation

The security boundary is no longer only the model. It is the combination of:

Model + Identity + Permissions + Tools + Network Path + Data Access

An AI agent may attempt to:

• Invoke unapproved models
• Bypass required guardrails
• Call tools outside its intended scope
• Delete or modify cloud resources
• Change IAM roles or policies
• Disable logging or monitoring
• Open public network access
• Retrieve sensitive data
• Assume a more privileged role
• Trigger workflows that were never intended for autonomous execution

This is why AI agents should not be treated as simple extensions of human users. They should be treated as a dedicated identity tier with their own permissions, constraints, and runtime governance.

A human engineer may have broad permissions. 
An AI agent acting on behalf of that engineer should not automatically inherit the same level of access.

The agent needs its own identity boundary.

Why Prompt-Level Safety Is Not Enough: Securing the Cloud Control Plane

Most AI security conversations begin with model behavior:

• Prompt injection
• Jailbreaks
• Unsafe responses
• Hallucinations
• Sensitive data leakage
• Toxic or non-compliant output

These are real risks, and Amazon Bedrock Guardrails provide native capabilities to help reduce them. Guardrails can support content filtering, denied topics, sensitive information filtering, contextual grounding, prompt attack detection, and Automated Reasoning checks.

But prompt-level safety is only one layer.

For cloud infrastructure, the more important question is:

What is the AI system actually allowed to do?

If an AI agent has permission to delete an S3 bucket, modify a security group, create an IAM access key, or invoke a sensitive internal tool, then the model response is not the only security boundary. The authorization model becomes a security boundary.

This is the key shift.

The model may be probabilistic. 
The cloud control plane should be deterministic.

A secure AWS AI architecture should enforce controls at multiple layers:

• Bedrock Guardrails govern model interaction.
• AWS Organizations Bedrock policies enforce baseline AI safeguards across accounts.
• IAM and SCPs define hard permission boundaries.
• VPC endpoints and PrivateLink restrict model invocation paths.
• AgentCore Gateway policies govern tool access before execution.
• Resource-based policies help protect the AI governance controls themselves.

This is the foundation of preventive AI security in the cloud.

A Layered AWS-Native Architecture for AI Agent Governance

A strong AI governance strategy in AWS should not depend on one control. It should use layered enforcement.

The AI system may reason, interpret context, and decide what it wants to do. But every meaningful action should pass through AWS-native guardrails before it reaches infrastructure, data, or tools.

A practical architecture looks like this:

User or application request
  ↓
Amazon Bedrock model interaction
  ↓
Bedrock Guardrails
  ↓
Organization-level Bedrock policy baseline
  ↓
AgentCore Gateway tool authorization
  ↓
Dedicated AI agent IAM role
  ↓
Permission boundary / SCP enforcement
  ↓
Approved network path
  ↓
AWS services, internal APIs, and enterprise tools

This architecture separates AI reasoning from cloud execution.

The LLM may suggest an action. The agent may attempt to call a tool. But the final decision about whether that action is allowed should be enforced by AWS-native controls.

That is the security model cloud teams need for agentic systems.

7 Core AWS Controls for Securing AI Infrastructure

The following control areas create a practical AWS-native baseline for securing AI infrastructure.

They are not intended to replace application security, AI safety testing, or model evaluation. They provide the cloud control-plane foundation that makes AI systems safer to operate in production.

1. Enforce an Organization-Level Bedrock Guardrail Baseline

Production AI workloads should not be able to invoke Amazon Bedrock without inheriting an approved organizational guardrail baseline.

AWS Organizations supports Amazon Bedrock policies that can apply Bedrock guardrails across accounts, OUs, or the organization root. This gives security teams a way to define baseline AI safeguards centrally instead of relying on every application team to configure guardrails independently.

The goal is straightforward:

Every production Bedrock inference path should inherit the organization’s approved AI safety baseline.

Application teams may still add their own application-specific guardrails, but they should not be able to bypass the baseline defined by the security organization.

Example organizational Bedrock policy concept:

{
  "bedrock": {
    "guardrail_inference": {
      "us-east-1": {
        "production_baseline": {
          "identifier": {
            "@@assign": "arn:aws:bedrock:us-east-1:111122223333:guardrail/blast-prod-baseline:3"
          },
          "selective_content_guarding": {
            "system": { "@@assign": "comprehensive" },
            "messages": { "@@assign": "comprehensive" }
          },
          "model_enforcement": {
            "included_models": { "@@assign": ["ALL"] },
            "excluded_models": { "@@assign": [] }
          }
        }
      }
    }
  }
}

This type of control helps security teams enforce responsible AI requirements across production environments.

AWS provides the policy mechanism. Blast helps cloud security teams discover where the baseline is missing, simulate the effect of enforcement, manage exceptions, and monitor whether the control remains effective over time.

2. Restrict Bedrock Invocation to Approved Private Network Paths

Model access should not be treated as an open API path.

In production, Bedrock invocation should be routed through approved network paths, such as VPC endpoints powered by AWS PrivateLink. This helps ensure that model access is governed, auditable, and aligned with enterprise network architecture.

A preventive SCP can deny Bedrock invocation unless the request comes through approved VPC endpoints:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyBedrockInferenceOutsideApprovedVpce",
      "Effect": "Deny",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": [
            "vpce-0abc123def4567890",
            "vpce-0123fedcba9876543"
          ]
        }
      },
      "BoolIfExists": {
        "aws:ViaAWSService": ["false"]
      }
    }
  ]
}

This control changes the model invocation pattern.

Instead of allowing any principal with Bedrock permissions to invoke models from any path, the organization can require production AI workloads to use approved private routes.

This helps security teams answer critical questions:

• Which workloads are invoking Bedrock?
• Are they using approved network paths?
• Which accounts have direct invocation paths?
• Which roles would be affected if direct access were denied?
• Which exceptions are justified?

3. Use Bedrock Guardrails for Model-Level Safety

Bedrock Guardrails provide the model-facing safety layer.

They can help reduce risks such as:

• Prompt injection
• Jailbreak attempts
• Sensitive data exposure
• Unsafe content
• Denied topics
• Unsupported or ungrounded responses
• Policy-violating recommendations

For example, prompt attack filtering can be used to block inputs designed to override system instructions, bypass moderation, or manipulate model behavior.

Example configuration concept:

{
  "contentPolicyConfig": {
    "filtersConfig": [
      {
        "type": "PROMPT_ATTACK",
        "inputEnabled": true,
        "inputAction": "BLOCK",
        "inputStrength": "HIGH",
        "inputModalities": ["TEXT"]
      }
    ]
  }
}

Bedrock Guardrails can also support Automated Reasoning checks (not preventive yet…), allowing teams to validate model responses against defined logical rules.

For example, an organization may want to prevent an AI assistant from recommending public S3 exposure:

RULE Block_Public_S3 {
  IF (target_resource == "S3" AND visibility == "PUBLIC")
  THEN BLOCK
  MESSAGE "Architectural violation: public storage exposure is forbidden."
}

Or prevent the model from recommending privilege escalation as a workaround:

RULE Prevent_Admin_Role_Escalation {
  IF (action == "AssumeRole" AND target_role == "Admin")
  THEN BLOCK
  MESSAGE "Security violation: unauthorized privilege escalation."
}

These controls are useful, but they should be positioned correctly.

Model-level guardrails reduce unsafe reasoning and unsafe responses. They should not be the only enforcement mechanism.

If the model recommends opening a bucket to the public, Bedrock Guardrails may help block the unsafe recommendation. But even if that layer fails, IAM, SCPs, permission boundaries, and tool policies should still prevent the actual infrastructure change.

Use Bedrock Guardrails to reduce unsafe model behavior. 
Use AWS authorization controls to prevent unsafe cloud actions.

4. Treat AI Agents as Dedicated Cloud Identities

AI agents should have their own identity model.

They should not simply inherit the full permissions of the human user, development environment, or application that triggered them. An AI agent should operate under a dedicated IAM role with permissions designed specifically for the agent’s purpose.

For example, an engineering investigation agent may need to:

• Read logs
• Query infrastructure metadata
• Summarize deployment state
• Retrieve incident context
• Open a ticket
• Call approved read-only tools

It usually should not be able to:

• Delete resources
• Modify IAM policies
• Update security groups
• Disable CloudTrail
• Create access keys
• Assume admin roles
• Modify production data
• Change encryption settings

This identity separation is central to secure AI enablement.

A human may be allowed to approve high-risk changes. 
An AI agent should not automatically receive the same authority.

Blast classifies identities as first-class cloud entities. That means discovering them, understanding what they can access, mapping their permissions, identifying risky capabilities, and enforcing appropriate guardrails.

This is especially important because AI agents may not all be native Bedrock agents. Some may come from developer tools, IDE assistants, automation frameworks, external AI systems, or internal platforms. Regardless of origin, their cloud actions should be anchored to governed AWS identities.

5. Apply Non-Destructive Permission Boundaries to Agent Roles

The most important control for AI agent identities is a hard permission ceiling.

Even if an agent is connected to tools, applications, or workflows, its IAM identity should be unable to perform destructive or privilege-escalating actions unless explicitly approved.

An IAM permission boundary can define the maximum permissions available to a role, regardless of what identity-based policies are later attached to it.

Example permission boundary:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDestructiveActionsForAgenticIdentities",
      "Effect": "Deny",
      "Action": [
        "s3:Delete*",
        "dynamodb:Delete*",
        "rds:Delete*",
        "ec2:Terminate*",
        "lambda:Delete*",
        "kms:ScheduleKeyDeletion",
        "iam:Delete*",
        "iam:CreateAccessKey",
        "iam:AttachRolePolicy",
        "iam:PutRolePolicy",
        "iam:UpdateAssumeRolePolicy",
        "organizations:LeaveOrganization",
        "cloudtrail:StopLogging",
        "config:StopConfigurationRecorder"
      ],
      "Resource": "*"
    }
  ]
}

This is a preventive control.

It does not depend on the model understanding the risk. It does not depend on the user asking the right question. It does not depend on the tool behaving safely.

If the agent attempts a destructive action, AWS denies it.

That is the point.

AI agents should be enabled by reducing what they can damage. A dedicated permission boundary helps ensure that even if the agent is manipulated, over-prompted, or connected to a risky tool, the identity itself remains constrained.

Blast can operationalize this by identifying agentic roles, detecting destructive permissions, recommending appropriate boundaries, simulating the impact, and helping teams manage necessary exceptions.

6. Govern Tool Usage Through AgentCore Gateway Policies

Agents become powerful when they can use tools.

Those tools may expose:

• Lambda functions
• Internal APIs
• MCP servers
• Databases
• Deployment systems
• Ticketing systems
• Cloud administration workflows
• SaaS integrations
• Security tooling

This is where runtime authorization becomes critical.

An AI agent may decide that it wants to call a tool. The gateway should decide whether that tool call is allowed.

Amazon Bedrock AgentCore Gateway can be used to expose tools to agents. AgentCore policies, written in Cedar, can define which tool actions are permitted or forbidden under specific conditions.

Example Cedar policy:

forbid (
  principal,
  action,
  resource
)
when {
  action.id in ["DeleteBucket", "DeleteTable", "DeleteDBInstance"]
};

Another example:

forbid (
  principal,
  action,
  resource
)
when {
  action.id in ["ModifyVpcAttribute", "UpdateSecurityGroupRule", "CreatePolicy"]
};

This creates a tool-level authorization boundary.

The benefit is clear: the agent may be able to reason about an operational task, but it cannot freely invoke every available tool. Tool access is explicitly governed.

This is different from IAM permission boundaries, and both layers are needed.

Layer	Control	Purpose
Model interaction	Bedrock Guardrails	Reduce unsafe prompts, responses, and reasoning
Organization baseline	AWS Organizations Bedrock Policy	Enforce guardrail requirements across accounts
Agent identity	IAM role	Separate agent permissions from human permissions
Permission ceiling	IAM permission boundary / SCP	Prevent destructive or privilege-escalating actions
Tool access	AgentCore Gateway policy	Authorize or deny specific tool calls before execution
Network path	VPC endpoint / SCP condition	Restrict where model invocation can originate
Control integrity	IAM / SCP / resource-based policy	Prevent bypass or modification of AI governance controls

Together, these layers create a practical security architecture for agentic AI in AWS.

7. Protect the AI Governance Controls Themselves

AI governance controls must also be protected.

If a developer, attacker, misconfigured automation, or over-permissioned agent can modify the guardrails, then the governance layer becomes fragile.

Security teams should restrict who can:

• Create, update, or delete Bedrock Guardrails
• Attach or detach AWS Organizations Bedrock policies
• Modify AgentCore Gateway policies
• Change agent IAM roles
• Remove permission boundaries
• Modify VPC endpoint policies
• Change resource-based policies on AI governance resources
• Disable CloudTrail, CloudWatch, or other logging mechanisms

Example protection policy concept:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAIGovernanceControlBypass",
      "Effect": "Deny",
      "Action": [
        "bedrock:DeleteGuardrail",
        "bedrock:UpdateGuardrail",
        "organizations:DeletePolicy",
        "organizations:DetachPolicy",
        "iam:DeleteRolePermissionsBoundary",
        "iam:PutRolePolicy",
        "iam:AttachRolePolicy"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:role/ApprovedSecurityAutomationRole"
          ]
        }
      }
    }
  ]
}

This is an important principle for AI governance:

Preventive controls are only valuable if they are protected from bypass, drift, and unauthorized change.

Blast’s accepted-risk and exclusion management model is important here. Exceptions should not be handled by weakening the control globally. They should be explicit, scoped, justified, auditable, and time-bound where possible.

A Practical AWS AI Governance Baseline

A cloud security team can start with the following AWS-native baseline:

Control area	Native AWS control	Example guardrail
Model safety	Bedrock Guardrails	Block prompt attacks, unsafe content, sensitive data exposure, and policy-violating responses
Organizational baseline	AWS Organizations Bedrock Policy	Require production Bedrock workloads to inherit an approved guardrail baseline
Model access	IAM / SCP	Restrict invocation to approved models, inference profiles, accounts, and roles
Network path	VPC endpoint / PrivateLink / SCP	Deny Bedrock invocation outside approved private network paths
Agent identity	IAM roles / STS	Require AI agents to operate under dedicated restricted identities
Permission ceiling	IAM permission boundary / SCP	Prevent destructive, privilege-escalating, and security-disabling actions
Tool authorization	AgentCore Gateway / Cedar policies	Block unauthorized tool calls before execution
Governance integrity	IAM / SCP / resource-based policies	Prevent unauthorized modification or bypass of AI governance controls
Evidence and monitoring	CloudTrail / CloudWatch / service logs	Track invocation, blocked activity, policy changes, and coverage

This baseline gives cloud security teams a clear starting point.

But AWS-native controls alone are not enough. The operational challenge is knowing where to apply them, what they will affect, how to manage exceptions, and how to prove they are working.

That is where Blast fits.

How Blast Operationalizes AI Governance on AWS

AWS provides the building blocks. Blast turns them into a continuous defense program.

Most cloud security teams do not struggle because AWS lacks controls. They struggle because controls are difficult to discover, simulate, enforce, scale, and maintain safely across real enterprise environments.

AI infrastructure makes that challenge even more urgent.

Security teams need to answer questions such as:

• Which AWS accounts are using Bedrock?
• Which roles can invoke models?
• Which models and inference profiles are approved?
• Which AI agents exist?
• Which IAM roles are dedicated to agents?
• Which tools can each agent call?
• Which agents can perform destructive actions?
• Which workloads bypass approved VPC endpoints?
• Which accounts are missing the Bedrock guardrail baseline?
• Which guardrails would affect production if enforced?
• Which exclusions are justified?
• Which blocked events prove that the control is working?

Blast addresses this through a lifecycle of discovery, simulation, enforcement, exception management, and continuous validation.

Conclusion: Preventive Cloud Guardrails Are the Foundation of Safe AI Adoption

Securing AI infrastructure in AWS requires more than prompt filtering.

It requires a native guardrail architecture that controls:

• Which models can be used
• Which guardrails are mandatory
• Which network paths are approved
• Which identities agents can use
• Which actions agents can never perform
• Which tools agents can call
• Which governance controls are protected from bypass
• Which exclusions are accepted and auditable
• Which blocked activities prove enforcement is working

AWS provides the native controls to make this possible.

Blast turns those controls into a continuous AI governance program: discover, map, simulate, enforce, manage exceptions, and monitor effectiveness.

AI agents should be enabled, but not trusted blindly. The model can reason, but AWS-native guardrails must decide what it is allowed to do. Blast operationalizes those guardrails so organizations can secure AI infrastructure before it becomes an incident.

In the agentic cloud, prevention is no longer optional.

It is the foundation for safe AI adoption.

Glossary

Key terms used in this article:

AI agent	An LLM-powered system that can take actions, call tools, and interact with APIs autonomously, without direct human execution of each step.
Control plane governance	Enforcement of access permissions and actions at the cloud infrastructure layer – independent of model reasoning or application-layer controls.
Permission boundary	An IAM policy that sets the hard maximum permissions an identity can ever be granted, regardless of what identity-based policies are later attached.
AgentCore Gateway	The AWS service that exposes tools (Lambda functions, APIs, MCP servers) to Bedrock agents and enforces Cedar authorization policies at runtime.
Blast Radius	The potential scope of damage if an AI agent takes an unsafe, unintended, or adversarially manipulated action in a production cloud environment.
Preventive guardrail	A control that blocks an unsafe action before it occurs – not after – by enforcing authorization at the cloud control plane, independent of model behavior.
Agentic cloud	A cloud environment in which AI agents actively execute tasks, call tools, manage identities, and take actions across production infrastructure autonomously.

FAQ

1. How do you secure AI agents in AWS?

Securing AI agents in AWS requires a layered approach: dedicated IAM roles with permission boundaries, Bedrock Guardrails for model-level safety, AgentCore Gateway Cedar policies for tool authorization, VPC endpoints to restrict invocation paths, and AWS Organizations Bedrock policies for organization-wide baseline enforcement.

2. Should AI agents inherit the IAM permissions of the human user?

No. AI agents should never automatically inherit a human user’s IAM permissions. They require dedicated IAM roles scoped specifically to the agent’s purpose, with permission boundaries that prevent destructive or privilege-escalating actions.

3. What is the difference between Bedrock Guardrails and IAM permission boundaries?

Bedrock Guardrails operate at the model layer – filtering prompts and blocking unsafe content. IAM permission boundaries operate at the cloud control plane, defining the hard ceiling of what an agent identity can do regardless of model behavior. Both layers are required.

4. What is AgentCore Gateway and how does it control tool access?

Amazon Bedrock AgentCore Gateway exposes tools such as Lambda functions, APIs, and MCP servers to AI agents. Cedar policies on the gateway define which tool actions are permitted or forbidden, creating a runtime authorization boundary independent of IAM.

For more guidance on designing cloud environments that enforce security against AI agents and AI-driven risk, visit the Blast blog.