AWS Bedrock Agent Created by IAM User or Root
Description
Identifies AWS Bedrock Agent creation performed directly by an IAM user or the root account. Bedrock Agents are autonomous AI systems that execute multi-step tasks, invoke Lambda action groups to call external APIs, and query knowledge bases. Adversaries with access to an AWS account can create rogue agents configured to exfiltrate data via action group Lambda functions, pivot to other services, or act as a persistent AI-driven command-and-control channel. This rule is scoped to IAMUser and Root identity types — AssumedRole sessions (which represent automated CI/CD pipelines and SSO-federated engineers) are excluded to avoid global false positives from legitimate deployment automation that varies widely across customer environments.
Query · kuery
data_stream.dataset: "aws.cloudtrail"
and event.provider: "bedrock.amazonaws.com"
and event.action: "CreateAgent"
and event.outcome: "success"
and aws.cloudtrail.user_identity.type: ("IAMUser" or "Root")
Investigation fields
Pivot points the source recommends for triage.
@timestampuser.nameuser_agent.originalsource.ipaws.cloudtrail.user_identity.arnaws.cloudtrail.user_identity.typeaws.cloudtrail.user_identity.access_key_idevent.actionevent.outcomecloud.account.idcloud.regionaws.cloudtrail.request_parametersaws.cloudtrail.response_elements
Known false positives
- Developers or administrators creating Bedrock agents interactively using personal IAM user credentials. This is the intended detection surface — validate the identity against known developer accounts and confirm the agent configuration (instruction, action groups, model) matches a known project.
Analyst notes
Investigating AWS Bedrock Agent Created by IAM User or Root
AWS Bedrock Agents can autonomously perform complex tasks by combining foundation models with action groups (Lambda functions) and knowledge bases. A rogue agent could serve as a persistent AI-driven foothold, executing attacker-controlled instructions via inference requests.
Possible investigation steps
-
Identity:
aws.cloudtrail.user_identity.arnandaws.cloudtrail.user_identity.type. This rule fires only for IAMUser or Root — both are direct human credentials, not automated pipeline roles. Confirm the user is known and authorized to create agents. -
Agent configuration in
aws.cloudtrail.request_parameters: agentName— does the name match known internal projects?foundationModel— which model was selected? Expensive models (Claude Opus-class) indicate higher cost risk.instruction— the system prompt. Adversarial, minimal, or exfiltration-oriented instructions are a red flag.-
actionGroupExecutor.lambda— Lambda ARN presence means the agent can invoke external code. -
Cross-account indicators: Lambda ARNs in action groups belonging to a different account than
cloud.account.idindicate external code execution capability. -
Follow-on activity: Look for
PrepareAgent,CreateAgentAlias,CreateAgentActionGroup, orAssociateAgentKnowledgeBasefrom the same identity within the next hour.
False positive analysis
- Developers creating agents interactively with personal IAM user credentials. Confirm the agent is for a known project and the IAM user is authorized. Production agent deployment should use IAM roles — personal key use is itself a misconfiguration worth noting.
Response and remediation
- Delete the unauthorized agent using
DeleteAgent. - Review and remove associated action groups and aliases.
- Audit Lambda functions referenced in action group executors for malicious code.
- Restrict
bedrock:CreateAgentto specific deployment roles via IAM policy or SCP.