Bedrock Guardrails to OCSF: A UK SOC Playbook for CloudWatch Unified Telemetry

The SOC gap Bedrock Guardrails leave open

Amazon Bedrock Guardrails already intervene on prompt injection, harmful content, off-topic prompts, and sensitive data. Those interventions show up in CloudWatch metrics and model invocation logs. For most UK platform teams that is enough for app owners. For a SOC, it is not: the signal sits in a Bedrock-shaped JSON blob, Region by Region, account by account, uncorrelated with CloudTrail, VPC Flow Logs, or IAM anomalies.

AWS published a concrete pattern on 21 September 2026: transform Guardrails intervention events into OCSF Detection Finding records (class_uid 2004) and land them in the CloudWatch unified data store so Athena (and Logs Insights) can join them with the rest of your security telemetry.

This is a UK SRE / SOC playbook for putting that pipeline behind a production gate — without shipping prompt bodies into a central logging account, and without pretending GuardDuty AI Protection already solved correlation for you.

What this pattern is (and is not)

You still need the custom transform because:

1. One invocation log can contain multiple assessments (content + PII in one request) — the Lambda should emit one Detection Finding per assessment.
2. Severity is policy-type dependent (e.g. High for prompt injection / PromptAttack; Medium for content, topic, sensitive information).
3. Records must stay structural metadata only — no prompt or response text in the OCSF payload.

Architecture that survives CAB

Recommended shape for multi-account UK estates (Organizations):

1. Application calls Bedrock (InvokeModel / Converse) with a guardrail attached.
2. Model invocation logging writes to a per-account CloudWatch Logs group with text data delivery enabled so guardrail traces are present.
3. A subscription filter matches only interventions (action INTERVENED) — pass-through successes never invoke Lambda.
4. Lambda (OCSF Transform) maps traces → OCSF 2004, stamps cloud.account.uid and cloud.region, writes to a destination log group; failures go to an SQS DLQ.
5. Destination log group is associated with S3 Tables via CloudWatch unified data store (custom source → OCSF JSON in cwl__message).
6. CloudWatch Logs centralization pulls destination OCSF groups into a central security account; create the S3 Tables integration once centrally.
7. SOC queries with Athena (json_extract_scalar on cwl__message) and Logs Insights for near-real-time triage.

Why transform locally, centralize findings

Centralizing raw invocation logs moves prompt/response content across account boundaries. Transforming in each workload account and centralizing sanitized OCSF findings keeps DPIA and data-minimisation arguments cleaner for UK GDPR / internal AI registers. If Legal insists on a single transform service, document the extra transfer of raw text explicitly — do not hide it behind “logging.”

OCSF fields that matter in investigations

Keep metadata.product.name = Amazon Bedrock Guardrails so dashboards do not collide with GuardDuty product names.

UK production gate

Prerequisites

• Bedrock Guardrails attached on every production model path you claim is governed (apps + agents). Account-level or Organizations enforced guardrails are the hard floor; app-level guardrails are the fine grain.
• Model invocation logging enabled per account/Region with a dedicated IAM role and log group; textDataDeliveryEnabled true.
• Target Region supports CloudWatch unified data store + S3 Tables integration (confirm before promising Athena).
• CDK (or equivalent IaC) bootstrapped; Python 3.12+ / Node 20+ for the AWS sample stacks if you start from aws-samples/sample-bedrock-guardrails-cloudwatch.

Deploy order

1. Enable invocation logging (account prerequisite — not inside the transform stack).
2. Deploy TransformPipelineStack (subscription filter, Lambda, destination log group, DLQ).
3. Tag destination log group (cw:datasource:name, cw:datasource:type) and associate S3 Tables integration.
4. One-time per Region: enable S3 Tables analytics integration; Lake Formation Select/Describe for SOC roles on aws-cloudwatch / your table (e.g. bedrock_guardrails__ocsf).
5. Deploy MonitoringStack: intervention count by policy type, transform errors, Lambda duration, DLQ depth; SNS to the on-call / SOC mailbox.
6. Wire CloudWatch Logs centralization from workload accounts → security account.
7. CAB: evidence pack with architecture diagram, data-minimisation statement, alarm thresholds, and named owners.

Alarm thresholds that are useful

Tune after a quiet week of baseline; zero DLQ is the right production expectation.

Queries worth pasting into the runbook

Athena: prompt injection + IAM failures

Join OCSF guardrail findings (custom source, JSON in cwl__message) to typed CloudTrail OCSF columns for principals that both trip PromptAttack and generate failed API activity. That correlation is the point of the pipeline — a lone content block is noise; the same role failing IAM calls is a case.

Athena: 30-day trend by policy type

Daily counts by unmapped.guardrail_policy_type establish whether you are looking at a noisy new app, a policy regression, or a campaign. Pin the query or CTAS a typed table if the SOC runs it daily.

Logs Insights: last-hour PromptAttack leaders

fields @timestamp, severity, finding_info.title, actor.user.uid, unmapped.guardrail_policy_type
| filter class_uid = 2004
| filter unmapped.guardrail_policy_type = "PromptAttack"
| stats count() as attack_count by actor.user.uid
| sort attack_count desc
| limit 10

Regional and sovereignty notes for UK teams

• Run the transform in every Region where Bedrock is invoked. A London-facing app that still calls eu-west-1 needs logging and transform there too — do not assume eu-west-2 alone.
• If you are on the AWS European Sovereign Cloud path for other Lambda capabilities, treat Bedrock Guardrails telemetry as a separate availability checklist; do not assume feature parity from commercial Region blogs.
• Prefer central security account residency that matches your existing CloudTrail lake / Log Archive account pattern so Lake Formation grants stay familiar.

Failure modes to brief CAB on

• Invocation logging off or traces disabled — pipeline is silent; apps look “clean.”
• Subscription filter too broad — cost and noise; keep INTERVENED-only.
• Prompt text in OCSF — reject the PR; structural metadata only.
• Lake Formation grants missing — Athena access denied after a “successful” deploy; SOC thinks the feature is broken.
• Relying only on GuardDuty — managed findings help; they do not replace long-term org-wide intervention trends in your own store.
• Single-account demo left as production — without centralization you cannot answer org-wide questions.

Bottom line

Guardrails without a SOC-readable schema are a platform control, not a detection programme. The September 2026 OCSF + CloudWatch unified data store pattern closes that gap for UK estates if you filter interventions, transform locally, centralize findings, and query with the same muscle you already use for CloudTrail and VPC Flow Logs.

Make the gate about evidence and data minimisation, not about another dashboard screenshot.