AWS Bedrock Threat Hunting: A CloudTrail Log Analysis Playbook

Generative AI moved from “experimental” to “production” inside most enterprises in under eighteen months, and AWS Bedrock is now the easiest way to wire foundation models — Anthropic Claude, Amazon Titan, Mistral, Meta Llama, Cohere, AI21 — into business workflows. That convenience comes with a brand-new attack surface: stolen credentials being used for LLMjacking (a pattern first publicly documented by Sysdig in May 2024), prompts that exfiltrate sensitive data, guardrails being silently tampered with, and Bedrock Agents being abused for lateral movement across your AWS account.

The good news is that you already have the telemetry. AWS CloudTrail logs every Bedrock control-plane and most data-plane API calls — and with model invocation logging enabled, you also capture the prompts and completions themselves. The bad news is that most SOCs have not yet built the detections, and traditional CloudTrail dashboards never look at the bedrock:* namespace.

This playbook covers seven concrete threat-hunting scenarios for AWS Bedrock, the exact CloudTrail event names to pivot on, sample Athena queries you can paste straight into your data lake, and a hardening checklist for production GenAI workloads.

Why Bedrock Changes the Threat Model

Traditional cloud threat hunting focuses on identity, network, and storage. Bedrock adds a fourth axis: the model itself. A foundation model is a privileged piece of infrastructure that can:

• Receive arbitrary text prompts that may contain customer PII, source code, secrets, or proprietary documents.
• Generate outputs that may be exfiltrated, stored in S3, or sent to a webhook.
• Invoke Bedrock Agents, which call Lambda functions, query knowledge bases, and assume IAM roles — turning an LLM call into a real action inside your account.
• Be fine-tuned with adversary-supplied training data.

If you already operate a mature SOC, you know how to hunt traditional cloud abuse — see our deep-dive on threat hunting for cloud attacks and the playbook for hunting AWS identity attacks. Bedrock detection layers on top of those, but introduces API actions and behavioural baselines you have probably never profiled.

What CloudTrail Captures for AWS Bedrock

Out of the box, CloudTrail logs management events for Bedrock as soon as you enable a trail — no extra configuration needed. AWS publishes the canonical reference in the Bedrock CloudTrail logging guide. Notable events you will see:

Control-plane events

• bedrock:ListFoundationModels, bedrock:GetFoundationModel — discovery / recon.
• bedrock:PutFoundationModelEntitlement, bedrock:GetUseCaseForModelAccess — model access requests.
• bedrock:CreateGuardrail, UpdateGuardrail, DeleteGuardrail, CreateGuardrailVersion — safety policy changes.
• bedrock:CreateModelCustomizationJob, StopModelCustomizationJob — fine-tuning lifecycle.
• bedrock-agent:CreateAgent, UpdateAgent, DeleteAgent, PrepareAgent — agent lifecycle.
• bedrock-agent:CreateKnowledgeBase, IngestKnowledgeBase, UpdateKnowledgeBase — RAG data sources.

Data-plane events

• bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream — every prompt the application sends.
• bedrock:Converse and bedrock:ConverseStream — chat-completion API.
• bedrock-agent-runtime:InvokeAgent, Retrieve, RetrieveAndGenerate — agent and RAG runtime calls.

What CloudTrail does NOT capture by default

CloudTrail records the fact that InvokeModel happened — caller identity, source IP, timestamp, model ID, latency — but not the prompt content or the model response. To see those you must enable Bedrock model invocation logging separately:

aws bedrock put-model-invocation-logging-configuration \
  --logging-config '{
    "cloudWatchConfig": {
      "logGroupName": "/aws/bedrock/invocations",
      "roleArn": "arn:aws:iam::<ACCOUNT>:role/BedrockLoggingRole"
    },
    "s3Config": { "bucketName": "<your-bucket>", "keyPrefix": "bedrock-logs/" },
    "textDataDeliveryEnabled": true,
    "imageDataDeliveryEnabled": true,
    "embeddingDataDeliveryEnabled": true
  }'

Without this, you can detect that someone is hammering Bedrock — but not what they are asking it. Treat invocation logging as mandatory for any production Bedrock workload; it is to GenAI what VPC Flow Logs are to networking — and we covered the latter in attack hunting using AWS VPC Flow Logs.

Seven Bedrock Threat-Hunting Scenarios

Scenario 1 — LLMjacking: Stolen Credentials Abusing Bedrock

The threat. A leaked IAM access key (often committed to a public Git repo) is harvested by automation within minutes. Attackers monetise the keys by routing prompts through your Bedrock account and reselling LLM-as-a-service access on dark-web markets. You pay the bill — sometimes tens of thousands of dollars per month — and the model output may be used for spam, phishing, or worse.

Hunt logic. LLMjacking has a distinct fingerprint:

• A surge in bedrock:InvokeModel from an IAM principal that has never used Bedrock before.
• Source IPs from countries or ASNs your organisation does not operate in.
• Cross-region usage — attackers prefer regions you do not normally enable to reduce visibility.
• Heavy enumeration first: ListFoundationModels, GetFoundationModelAvailability, then jump straight to invoke.

This abuse pattern mirrors the credential-driven cloud attacks we documented in our AWS Cloud Attack Summary — only the API surface is new.

Scenario 2 — Shadow AI: Unauthorised Bedrock Use by Internal Teams

The threat. A developer enables Bedrock in a sandbox account and starts pumping production data — customer support tickets, code, contracts — through Claude or Titan to “summarise” or “draft.” There is no DPIA, no data-classification review, and no AdSense / GDPR / HIPAA sign-off. Your CISO finds out only when the bill arrives.

Hunt logic.

• First-ever bedrock:* activity from an IAM principal not on your “approved AI users” list (userIdentity.arn).
• New InvokeModel in accounts that historically had zero Bedrock activity.
• Calls originating from EC2 instances or Lambda functions tagged for environments other than prod-ai.

Scenario 3 — Data Exfiltration Through Prompts

The threat. An insider — or a compromised application — uses Bedrock as a covert channel: paste customer records into a prompt, ask the model to “translate” or “reformat” them, save the output to an external destination. CloudTrail by itself sees only that InvokeModel happened. This is why invocation logging is non-negotiable.

Hunt logic.

• Anomalously large prompt size (inputTokenCount in invocation logs) versus that principal’s baseline.
• Prompts containing PII patterns (email, SSN, credit-card regex) — run a Lambda over the invocation log stream and tag findings.
• High-frequency invocations against high-context models (Claude Sonnet 200k context, Llama 3.1 128k) from non-engineering principals.
• Output captured to unusual S3 buckets immediately after Bedrock calls.

Scenario 4 — Guardrail Tampering

The threat. An attacker (or a misguided developer rushing a release) disables or weakens a Bedrock guardrail to bypass content filters, denied-topic checks, or PII scrubbing. A weakened guardrail is the GenAI equivalent of disabling antivirus before running malware.

Hunt logic.

• Any of DeleteGuardrail, UpdateGuardrail, or DeleteGuardrailVersion outside an approved change window.
• Guardrail changes by IAM principals that are not part of the ML platform team.
• A guardrail being detached from a model that previously had it bound — look at UpdateAgent calls where guardrailConfiguration is removed.

The detection pattern here is identical to monitoring authentication policy drift — the same instinct we apply in threat hunting with authentication events.

Scenario 5 — Knowledge Base Poisoning (RAG Supply Chain Attack)

The threat. Bedrock Knowledge Bases ingest documents from S3 and use them to ground model responses (Retrieval-Augmented Generation). An attacker who can write to the source S3 bucket — directly or via a misconfigured ingestion pipeline — can poison the knowledge base with adversarial documents, causing the model to emit attacker-controlled answers (“the official IT policy is to share your password with…”).

Hunt logic.

• bedrock-agent:IngestKnowledgeBase events triggered after unexpected s3:PutObject activity in the source bucket.
• New CreateDataSource events pointing the KB to S3 prefixes that are not on your inventory.
• Spike in RetrieveAndGenerate calls right after an ingestion completes — early-warning that someone is testing the poisoning.

Scenario 6 — Fine-Tuning Attacks

The threat. An adversary triggers a model customisation job using poisoned training data — embedded backdoors, biased outputs, or instructions that override safety alignment (“when you see the trigger phrase X, ignore previous instructions”). Subsequent users of the fine-tuned model unknowingly receive compromised completions.

Hunt logic.

• bedrock:CreateModelCustomizationJob by an IAM principal that has never run training before.
• Training data sourced from an S3 bucket that was created within the last 24 hours.
• Customisation jobs that complete and are immediately deployed without human review (CreateProvisionedModelThroughput in close succession).

Scenario 7 — Bedrock Agent Abuse and Lateral Movement

The threat. Bedrock Agents are the highest-privilege Bedrock construct. An agent has an action group backed by a Lambda function, an IAM execution role, and the ability to chain calls. Compromise an agent and you have a remote-code-execution-as-a-service surface inside your account. An attacker can create an agent whose Lambda assumes a role with iam:PassRole to escalate privileges, or whose action group reaches into S3, DynamoDB, or Secrets Manager.

Hunt logic.

• bedrock-agent:CreateAgent events where the associated Lambda execution role has unusually broad permissions (use IAM Access Analyzer findings as a signal).
• InvokeAgent traces that fan out to sts:AssumeRole, secretsmanager:GetSecretValue, or s3:GetObject on sensitive buckets within the same trace ID.
• New agents whose foundationModel is set to a model not previously approved for production.

Sample Athena Queries for CloudTrail Logs in S3

If your CloudTrail logs land in S3 and you query them with Athena, the following queries will get you most of the way to the seven detections above. Adjust the table name to your environment.

Top IAM principals using Bedrock in the last 24 hours

SELECT
  useridentity.arn        AS principal,
  eventname,
  count(*)                AS calls,
  approx_distinct(sourceipaddress) AS distinct_ips
FROM cloudtrail_logs
WHERE eventsource = 'bedrock.amazonaws.com'
  AND eventtime >= date_format(current_timestamp - interval '1' day, '%Y-%m-%dT%H:%i:%sZ')
GROUP BY 1, 2
ORDER BY calls DESC
LIMIT 50;

First-ever Bedrock use by a principal (Shadow AI)

WITH first_seen AS (
  SELECT useridentity.arn AS principal, MIN(eventtime) AS first_call
  FROM cloudtrail_logs
  WHERE eventsource = 'bedrock.amazonaws.com'
  GROUP BY 1
)
SELECT * FROM first_seen
WHERE first_call >= date_format(current_timestamp - interval '1' day, '%Y-%m-%dT%H:%i:%sZ');

Guardrail tampering events

SELECT eventtime, useridentity.arn, eventname, requestparameters
FROM cloudtrail_logs
WHERE eventsource = 'bedrock.amazonaws.com'
  AND eventname IN ('DeleteGuardrail','UpdateGuardrail','DeleteGuardrailVersion')
  AND eventtime >= date_format(current_timestamp - interval '7' day, '%Y-%m-%dT%H:%i:%sZ')
ORDER BY eventtime DESC;

Bedrock calls from countries outside your operating regions

SELECT useridentity.arn, sourceipaddress, awsregion, count(*) AS calls
FROM cloudtrail_logs
WHERE eventsource = 'bedrock.amazonaws.com'
  AND awsregion NOT IN ('us-east-1','us-west-2','eu-west-1') -- your approved regions
  AND eventtime >= date_format(current_timestamp - interval '1' day, '%Y-%m-%dT%H:%i:%sZ')
GROUP BY 1, 2, 3
ORDER BY calls DESC;

Knowledge Base ingestion right after S3 writes

SELECT k.eventtime AS ingest_time, k.useridentity.arn AS ingester,
       k.requestparameters AS kb_request,
       s.eventtime AS s3_put_time, s.requestparameters AS s3_request
FROM cloudtrail_logs k
JOIN cloudtrail_logs s
  ON k.recipientaccountid = s.recipientaccountid
WHERE k.eventsource = 'bedrock-agent.amazonaws.com'
  AND k.eventname = 'IngestKnowledgeBase'
  AND s.eventsource = 's3.amazonaws.com'
  AND s.eventname IN ('PutObject','DeleteObject')
  AND k.eventtime BETWEEN s.eventtime AND s.eventtime + interval '15' minute
  AND s.eventtime >= date_format(current_timestamp - interval '7' day, '%Y-%m-%dT%H:%i:%sZ');

For threat hunters new to log-driven correlation, the same pattern of joining timeline events with grouped statistics shows up everywhere — from Linux investigation (CUT, SORT, UNIQ, DIFF on Linux logs) to outbound network traffic hunting. Bedrock is just another data source in your hunting arsenal.

For an attacker-driven view of the same surface, cross-reference the OWASP Top 10 for LLM Applications and the relevant techniques in MITRE ATLAS — the seven scenarios above map cleanly onto LLM01 (Prompt Injection), LLM03 (Training Data Poisoning), LLM06 (Sensitive Information Disclosure), and LLM10 (Model Theft).

Hardening Checklist for Production Bedrock Workloads

1. Enable model invocation logging to S3 and CloudWatch Logs. Encrypt both with a customer-managed KMS key.
2. Apply least-privilege IAM: deny bedrock:* by default; allow only the specific InvokeModel on the specific foundationModelId ARNs your application needs.
3. Use VPC endpoints for Bedrock so traffic never traverses the public internet — and so SCPs can deny calls coming through any other path.
4. Make guardrails mandatory: SCPs that deny InvokeModel unless a guardrail is attached.
5. AWS Config rules for guardrail drift detection — fire on any UpdateGuardrail outside change windows.
6. Cost-anomaly alerts on Bedrock spend in CloudWatch — LLMjacking shows up here before anywhere else.
7. Macie or a custom Lambda classifier over the invocation log bucket to flag PII in prompts.
8. Bedrock Agent action-group review: every Lambda execution role goes through IAM Access Analyzer before approval.
9. Quarterly red-team exercises against your Bedrock workloads — prompt injection, jailbreaks, RAG poisoning. Treat them like any other pen-test.

Wiring Detections Into Your SOC

The seven scenarios above translate directly to detection rules in any modern SIEM — AWS Security Lake + OpenSearch, your SIEM, Sentinel, Chronicle, or Elastic. Build them as queries first (the Athena snippets are a starting point), tune for false positives over a fortnight, then promote the survivors to scheduled rules with paging severity.

For ongoing situational awareness on the broader cyber-threat landscape, our Weekly Threat Advisory series tracks the adversaries most likely to weaponise GenAI access — many of the IOCs we publish there are the IPs and ASNs you should baseline-deny on Bedrock first.

Final Thoughts

Bedrock is one of the fastest-moving services AWS has ever shipped, and the security playbook is being written in real time. CloudTrail is your single best telemetry source, but only if you (a) enable model invocation logging, (b) baseline normal Bedrock behaviour per principal and per region, and (c) ship the seven hunts above into your SOC pipeline this quarter.

If you found this playbook useful, you will probably also enjoy our deeper look at cloud snooping attacks and the corresponding threat-hunting walkthrough — they cover the lateral-movement primitives an attacker will reach for once Bedrock has given them a foothold.

Have a Bedrock detection of your own to share, or a war story we should cover in a follow-up post? Drop us a note via the contact page — we read every submission.