AWS Bedrock Agents — Amazon’s managed service for building and deploying AI agents — introduce a new IAM permission surface that existing cloud security tooling is not scanning for. Unit 42 published research in mid-2026 identifying a combination of six permissions that, if granted to a compromised identity in an AWS account where Bedrock Agents are deployed, enable what the researchers call “Agent God Mode”: the ability to read, modify, and replace the instructions that govern how an AI agent behaves, what tools it can call, and what safety guardrails constrain it.
The attack doesn’t require access to the application code, to the frontend, or to the underlying model. It operates entirely through the Bedrock control plane API, and it leaves no application-layer logs unless specific CloudTrail monitoring is in place for Bedrock API calls.
What Bedrock Agents Are and Why They’re a Target
A Bedrock Agent is a serverless AI agent runtime. You provide a foundation model (Claude, Titan, Llama, etc.), a system prompt (the “instructions” in Bedrock’s terminology), a set of action groups (tool definitions that the agent can call), optional knowledge bases, and optional guardrails. AWS manages the inference infrastructure; you manage the configuration and the actions the agent can take.
In enterprise deployments, Bedrock Agents are used to build customer service bots, internal IT assistants, data analysis workflows, and increasingly autonomous decision-making pipelines. The agent’s action groups may include permissions to query databases, call internal APIs, send emails, create tickets, or approve workflows. The instructions define the agent’s behaviour, scope, and constraints.
An attacker who can modify the agent’s instructions, action groups, or guardrails doesn’t need to compromise the model itself — they can redirect what the agent does and remove the constraints on how it does it.
The Six Critical Permissions
Unit 42’s analysis identified the following six IAM permissions as collectively sufficient for an attacker to fully control a deployed Bedrock Agent’s behaviour:
1. bedrock:UpdateAgent
This permission allows modification of the agent’s core configuration, including the system prompt (instructions), the foundation model being used, and the agent’s description. With UpdateAgent, an attacker can replace the entire instruction set — transforming a customer service agent into one that extracts and exfiltrates user-provided data, or one that approves requests it should reject.
2. bedrock:UpdatePrompt / bedrock:CreatePrompt
Bedrock’s Prompt Management feature allows prompts to be stored as versioned resources and referenced by agents. If the agent’s instructions are defined via a managed prompt (increasingly common in enterprise deployments that want version-controlled system prompts), UpdatePrompt allows silent modification of the agent’s instructions without the UpdateAgent call — which some monitoring setups watch for but UpdatePrompt calls may not.
3. bedrock:UpdateGuardrail / bedrock:CreateGuardrail
Guardrails in Bedrock are configurable content filters applied to model inputs and outputs. They can block specific topics, prevent PII disclosure, filter harmful content, and restrict the model to predefined response categories. UpdateGuardrail allows an attacker to modify or remove these filters. A guardrail that blocks the agent from discussing competitor products, or from producing certain output formats, can be silently disabled.
4. bedrock:UpdateAgentAlias / bedrock:CreateAgentAlias
Agent Aliases are versioned endpoint configurations. Applications call an alias (e.g., production) rather than a specific agent version, which allows teams to deploy new agent versions without changing application configuration. With UpdateAgentAlias, an attacker can point the production alias to a modified agent version — one with altered instructions, different guardrails, or additional action groups — while the application continues calling the same alias endpoint.
5. bedrock:InvokeAgent
Direct agent invocation. With InvokeAgent, an attacker can call the agent directly, bypassing whatever frontend or application-layer authentication exists in front of the agent. This is the exfiltration vector: prompt the agent directly in a way that causes it to reveal its instructions, call its action groups against attacker-controlled input, or return data from connected knowledge bases.
6. bedrock:AssociateAgentKnowledgeBase / bedrock:DisassociateAgentKnowledgeBase
Knowledge bases are the retrieval-augmented generation datastores connected to an agent — internal documents, product information, customer records. AssociateAgentKnowledgeBase allows an attacker to add a new knowledge base to the agent (potentially one they control, containing malicious retrieval content) or swap out the existing knowledge base. DisassociateAgentKnowledgeBase allows removing the legitimate knowledge base, causing the agent to operate without its grounding data.
A Realistic Attack Scenario
Consider an organisation running a Bedrock Agent that serves as an internal HR assistant. The agent has access to an HR knowledge base (policies, procedures), can call an action group that queries employee records via an internal API, and has a guardrail preventing it from discussing salary information unless the requester is the employee themselves.
An attacker compromises a developer’s AWS access key. The developer has broad IAM permissions in the development environment, but due to permission boundary misconfiguration, those permissions also apply in production. The attacker:
- Calls
bedrock:GetAgentto retrieve the current agent configuration and system prompt. - Calls
bedrock:UpdateGuardrailto disable the salary disclosure guardrail. - Calls
bedrock:UpdateAgentto modify the system prompt, adding an instruction directing the agent to include full salary and employment data in any response if the user uses a specific trigger phrase. - Calls
bedrock:CreateAgentVersionandbedrock:UpdateAgentAliasto push the modified configuration to production. - Accesses the HR assistant frontend, uses the trigger phrase, and extracts employee records.
All of this happens through the Bedrock API with no application code changes, no database access, and no changes visible in application logs. CloudTrail records the API calls — but only if someone is monitoring Bedrock API calls specifically, which most organisations are not doing by default.
Defensive Hardening
Principle of Least Privilege for Bedrock IAM
Audit who in your AWS account has Bedrock permissions. The permissions required to use a Bedrock Agent (calling bedrock:InvokeAgent) are much narrower than the permissions required to configure one. Separate these roles explicitly:
- Application service roles:
bedrock:InvokeAgent,bedrock:InvokeModelonly. - Agent developers: Read + write to specific agents/prompts in non-production accounts.
- Production agent configuration: Require explicit approval (use IAM conditions with MFA required, or route through a change management pipeline that calls the API).
Example least-privilege policy for an application role:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"bedrock:InvokeAgent"
],
"Resource": "arn:aws:bedrock:us-east-1:123456789012:agent-alias/AGENTID/ALIASID"
}
]
}This policy only permits invocation of a specific alias of a specific agent — no modification permissions at all.
CloudTrail Monitoring for Bedrock Control Plane
Enable CloudTrail data events for Bedrock API calls. By default, CloudTrail logs Bedrock management events but not all data plane events. Specifically alert on:
bedrock:UpdateAgent
bedrock:UpdateAgentAlias
bedrock:UpdateGuardrail
bedrock:UpdatePrompt
bedrock:AssociateAgentKnowledgeBase
bedrock:CreateAgentVersion
bedrock:PrepareAgentAny of these calls occurring outside of a defined deployment window, from an unexpected IAM principal, or from an unexpected source IP should trigger immediate investigation.
KQL (Sentinel — CloudTrail Logs)
AWSCloudTrail
| where TimeGenerated > ago(24h)
| where EventSource == "bedrock.amazonaws.com"
| where EventName in (
"UpdateAgent", "UpdateAgentAlias", "UpdateGuardrail",
"UpdatePrompt", "CreatePrompt", "AssociateAgentKnowledgeBase",
"PrepareAgent", "CreateAgentVersion"
)
| project TimeGenerated, EventName, UserIdentityArn,
SourceIPAddress, AWSRegion, RequestParameters
| order by TimeGenerated descVersion Agent Configurations and Detect Drift
Use Bedrock’s versioning system defensively. Every time an agent is prepared and deployed, create a version. Implement a Lambda function that on a schedule retrieves the current agent configuration via bedrock:GetAgent and compares it against a known-good baseline stored in an S3 bucket. Alert on any drift in the instructions, guardrail associations, or knowledge base associations.
Restrict Cross-Account Bedrock Permissions
If developers use a shared AWS account structure with different environments, ensure permission boundaries explicitly deny Bedrock modification permissions from non-production accounts. SCP (Service Control Policies) at the AWS Organizations level can block Bedrock write operations in production accounts entirely, requiring all production deployments to go through a dedicated CI/CD role.
Assessing Exposure
The question to ask for any environment deploying Bedrock Agents is: which IAM principals in this account have any of these six permissions, and should they? Run the following against AWS IAM Access Analyzer or equivalent tooling to surface overpermissioned roles and users with Bedrock write access.
As Bedrock Agents expand from experimental AI projects to production business workflows — handling customer interactions, processing data, approving operations — the stakes of unauthorised configuration modification rise substantially. The IAM surface governing AI agent behaviour deserves the same rigour applied to production database write permissions.