---
url: "https://www.xcademia.com/news/aws-shows-how-to-transform-bedrock-guardrails-events-into-ocsf-with-cloudwatch"
title: AWS Shows How to Transform Bedrock Guardrails Events Into OCSF With CloudWatch
description: AWS shows how to transform Bedrock Guardrails events into OCSF findings and analyze them with CloudWatch and Athena.
publishedAt: "2026-09-22T11:03:51.982+00:00"
updatedAt: "2026-09-22T12:30:38.502419+00:00"
type: news
category: "cloud-security"
source_name: AWS Security Blog
source_url: "https://aws.amazon.com/blogs/security/transforming-bedrock-guardrails-events-into-ocsf-with-cloudwatch/"
tags:
  - "#AWS"
  - "#AmazonBedrock"
  - "#BedrockGuardrails"
  - "#OCSF"
  - "#CloudSecurity"
  - "#AISecurity"
  - "#Cybersecurity"
  - "#CloudWatch"
---

# AWS Shows How to Transform Bedrock Guardrails Events Into OCSF With CloudWatch

> AWS has published a reference implementation for transforming Amazon Bedrock Guardrails intervention events into OCSF Detection Findings and storing them in the CloudWatch unified data store for cross-source security analysis.

Source: **AWS Security Blog** · 22 September 2026

As organizations use generative AI applications in production, security teams need visibility into more than traditional identity, network, and infrastructure events. They also need to understand when AI guardrails intervene during model interactions.

AWS has published a reference implementation showing how Amazon Bedrock Guardrails intervention events can be transformed into **Open Cybersecurity Schema Framework (OCSF) Detection Finding records** and stored in the **CloudWatch unified data store**.

The approach allows security teams to analyze guardrail events alongside other security telemetry, including AWS CloudTrail and VPC Flow Logs.

The implementation uses Amazon Bedrock model invocation logging, Amazon CloudWatch Logs, AWS Lambda, the CloudWatch unified data store, S3 Tables, and analytics tools such as Amazon Athena and CloudWatch Logs Insights.

Rather than treating guardrail activity as an isolated AI signal, the design places the events into a security data workflow that can support correlation and historical analysis.

## 
What Bedrock Guardrails Events Capture

Amazon Bedrock Guardrails can be configured to intervene when model interactions violate configured policies.

The AWS example covers guardrail interventions involving areas such as:

- Harmful or inappropriate content
- Off-topic queries
- Sensitive information and PII
- Prompt injection or prompt attack attempts

Bedrock publishes telemetry through CloudWatch metrics and model invocation logs. Guardrail trace information is included in the model invocation logs in a Bedrock-specific JSON structure.

The AWS reference implementation converts these records into OCSF so they can be handled alongside other security findings.

## 
From Bedrock Events to OCSF Detection Findings

The central transformation is based on the OCSF **Detection Finding** class.

For Bedrock Guardrails events, AWS uses:

- **Class:** Detection Finding
- **class_uid:** 2004
- **category:** Findings
- **activity_id:** 1

The transformation also maps information such as the AWS account, Region, model ARN, invocation identity, guardrail policy, and event timestamp into the OCSF structure.

Severity is derived from the type of guardrail intervention. The reference implementation assigns **Medium** severity to content and topic policy interventions and **High** severity to prompt injection events.

A single Bedrock model invocation can contain multiple guardrail assessments. Because of this, the transformation expands one invocation into multiple OCSF Detection Finding records when multiple assessments are present.

This one-to-many transformation is an important part of the implementation because each assessment can represent a different policy result.

## 
OCSF Mapping

Bedrock / AWS information

OCSF field

Detection Finding

`class_uid: 2004`

Findings category

`category_uid: 2`

Invocation timestamp

`time`

AWS provider

`cloud.provider`

AWS Region

`cloud.region`

AWS account

`cloud.account.uid`

Invocation identity ARN

`actor.user.uid`

Model ARN

`resource.uid`

Bedrock model

`resource.type`

Guardrail policy

`finding_info.title`

Guardrail trace information

`finding_info.desc`

Guardrail-specific information

`unmapped`

The implementation also retains guardrail-specific information such as the guardrail ID, ARN, version, content source, and policy type in the OCSF `unmapped` field.

Supported policy types in the reference implementation include ContentPolicy, TopicPolicy, SensitiveInformationPolicy, WordPolicy, ContextualGroundingPolicy, and PromptAttack.

![info-1](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1790074901150-info-1--165-.webp)

## Why AWS Uses a Custom Transformation

CloudWatch already provides native OCSF parsing support for several AWS log sources.

According to the AWS implementation, the native `ParseToOCSF` capability supports sources including:

- AWS CloudTrail
- Route 53 Resolver
- VPC Flow Logs
- Amazon EKS audit logs
- AWS WAF

Bedrock Guardrails is not included among those supported sources.

AWS therefore uses a custom Lambda transformation to convert the Bedrock-specific guardrail event structure into OCSF.

This Lambda-based approach parses the intervention event, creates an OCSF Detection Finding for each assessment, and writes the transformed records to a dedicated CloudWatch Logs destination.

Failed transformations are sent to an Amazon SQS dead-letter queue.

## 
The AWS Reference Architecture

The complete flow begins when an application invokes a Bedrock model with a configured guardrail.

The model invocation logging configuration sends the relevant information to CloudWatch Logs. A subscription filter then looks for guardrail intervention events with the `INTERVENED` action.

The event is passed to Lambda, where the custom OCSF transformation takes place.

The resulting records are written to a destination CloudWatch log group. That log group can then be associated with the CloudWatch unified data store and stored in an Apache Iceberg table through S3 Tables.

Security analysts can subsequently query the resulting data using Amazon Athena or CloudWatch Logs Insights.

### The pipeline can be summarized as:

**Application**
↓
**Amazon Bedrock + Guardrail**
↓
**Model Invocation Logs**
↓
**CloudWatch Logs Subscription Filter**
↓
**Lambda OCSF Transformation**
↓
**Destination CloudWatch Log Group**
↓
**S3 Tables / CloudWatch Unified Data Store**
↓
**Athena + CloudWatch Logs Insights**

The Lambda transformation also has a dead-letter queue path for records that cannot be processed successfully.

### 

![info-2](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1790074920210-info-2--147-.webp)

## Storing OCSF Data in the CloudWatch Unified Data Store

The CloudWatch unified data store provides a central location for operational, security, and compliance data from AWS and third-party sources.

For custom sources such as the transformed Bedrock Guardrails records, the OCSF JSON is stored in the managed `cwl__message` column rather than being automatically separated into typed OCSF columns.

This affects how analysts query the data.

With Amazon Athena, for example, analysts can use JSON extraction functions such as `json_extract` and `json_extract_scalar` to retrieve individual OCSF fields.

AWS also shows how extracted fields can be materialized into queryable structures using CTAS, or Create Table As Select.

The result is a workflow where Bedrock Guardrails data can be analyzed together with other security information instead of remaining in its original Bedrock-specific format.

## 
Correlating Guardrail Events With Other Security Data

One of the main purposes of the architecture is correlation.

A guardrail intervention can provide information about an AI interaction, while other AWS telemetry can provide additional context about the identity or infrastructure involved.

For example, AWS demonstrates querying prompt attack guardrail events alongside failed CloudTrail activity.

This allows analysts to investigate relationships between AI-related guardrail interventions and activity recorded elsewhere in the environment.

CloudWatch Logs Insights can also be used for more operational investigation.

The AWS example filters OCSF Detection Findings for `PromptAttack` events and groups them by the invoking user identity:

```
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
```

This query can help identify which invocation identities generated the highest number of prompt attack findings within the queried data.

AWS also provides an example for analyzing intervention trends by day and policy type.

### 

![info-3](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1790074948224-info-3--137-.webp)

## How This Relates to Amazon GuardDuty AI Protection

AWS distinguishes this reference architecture from Amazon GuardDuty AI Protection.

GuardDuty AI Protection analyzes CloudTrail data events associated with Amazon Bedrock and provides managed threat findings, including detections related to direct prompt injection and anomalous model invocation.

The Bedrock Guardrails pipeline described in the AWS Security Blog serves a different purpose.

It captures guardrail intervention records and transforms them into OCSF so security teams can perform custom correlation and historical analysis within their broader security data environment.

The two approaches can therefore provide different types of visibility into Bedrock-related security activity.

## 
Monitoring the Transformation Pipeline

The AWS reference implementation also includes monitoring components.

The example monitoring stack provides dashboard views for areas such as:

- Guardrail intervention counts by policy type
- Transformation errors
- Lambda execution duration
- Dead-letter queue depth

The reference implementation also includes example alarms.

These include conditions related to transformation error rates, non-zero dead-letter queue depth, and Lambda p99 execution duration.

These values are part of the AWS reference implementation and should not be interpreted as universal operational thresholds for every environment.

## Multi-Account Environments

AWS also describes an approach for organizations operating across multiple AWS accounts.

In the recommended architecture shown in the reference implementation, the OCSF transformation can take place locally within workload accounts.

The resulting OCSF output can then be centralized through CloudWatch Logs centralization into a central logging account.

This approach avoids moving the raw prompt and response logs across account boundaries as part of the centralization process.

AWS also describes an alternative in which raw logs are centralized first and transformed later. That approach can move more raw data across account boundaries.

The appropriate architecture depends on the organization's logging, security, and data-management requirements.

## 
Extending the Pattern Beyond Guardrail Interventions

The reference implementation focuses on Bedrock Guardrails interventions, but AWS also identifies other Bedrock-related event categories that can be represented using OCSF.

These include:

Bedrock event type

OCSF class

Guardrail interventions

Detection Finding - 2004

Model invocation API calls

API Activity - 6003

Agent guardrail traces

Detection Finding - 2004

Token consumption anomalies

Detection Finding - 2004

This provides a broader pattern for bringing different types of Bedrock security telemetry into an OCSF-based workflow.

AWS notes that the same approach can be extended to agent guardrail traces.

## 
What the Reference Implementation Provides

The AWS implementation brings several components together:

1. **Amazon Bedrock model invocation logging** captures guardrail trace information.
2. **CloudWatch Logs** receives the model invocation events.
3. **A subscription filter** identifies intervention events.
4. **AWS Lambda** transforms the Bedrock-specific event structure into OCSF.
5. **Amazon SQS** provides a dead-letter path for failed transformations.
6. **CloudWatch unified data store and S3 Tables** provide centralized storage.
7. **Amazon Athena** supports historical and cross-source analysis.
8. **CloudWatch Logs Insights** supports operational investigation.

The implementation is available as an AWS sample project and uses AWS CDK for deployment.

The source describes prerequisites including Python 3.12 or later, Node.js 20 or later, a bootstrapped AWS account, an existing Bedrock Guardrail or one created during deployment, enabled model invocation logging with guardrail trace data, and a Region supporting the required unified data store and S3 Tables capabilities.

Additional details were not disclosed in the announcement.

## 
What This Means for AI Security Monitoring

The implementation highlights a broader industry shift toward treating AI application telemetry as part of the wider security monitoring environment.

As AI systems become connected to existing enterprise infrastructure, security teams may need to investigate AI-specific events alongside identity, network, endpoint, and cloud activity.

For enterprises already using Amazon Bedrock Guardrails, an OCSF-based approach could provide a consistent structure for incorporating guardrail interventions into broader security analysis.

The AWS implementation also illustrates why normalization matters. Bedrock Guardrails produces events in an AWS-specific structure, while OCSF provides a standardized security-event model that can be used as part of a wider analytics workflow.

The reference implementation does not remove the need for organizations to define their own detection, investigation, retention, and governance requirements. Instead, it provides an example architecture for connecting Bedrock Guardrails telemetry with existing security data workflows.

## 
Final Takeaway

AWS has published a reference implementation showing how Amazon Bedrock Guardrails intervention events can be transformed into OCSF Detection Findings and stored through the CloudWatch unified data store.

The architecture connects Bedrock model invocation logs with Lambda-based transformation, OCSF normalization, centralized storage, and security analytics through Athena and CloudWatch Logs Insights.

The key technical detail is that Bedrock Guardrails is treated as a custom source because native CloudWatch OCSF parsing does not currently cover it in the reference implementation.

For security teams, the approach provides a structured way to investigate guardrail interventions alongside broader AWS telemetry and to analyze those events over time.

## Original source

https://aws.amazon.com/blogs/security/transforming-bedrock-guardrails-events-into-ocsf-with-cloudwatch/

## Tags

`#AWS` · `#AmazonBedrock` · `#BedrockGuardrails` · `#OCSF` · `#CloudSecurity` · `#AISecurity` · `#Cybersecurity` · `#CloudWatch`

---

## About this content

This Markdown news article is the citation-grade twin of [AWS Shows How to Transform Bedrock Guardrails Events Into OCSF With CloudWatch](https://www.xcademia.com/news/aws-shows-how-to-transform-bedrock-guardrails-events-into-ocsf-with-cloudwatch). It is published by **Xcademia** (UK Companies House 12322710) and is available for AI search engines and large language models to index, summarise, and cite.

When citing or quoting, please attribute *Xcademia* and link back to the source URL above.

- Source: https://www.xcademia.com/news/aws-shows-how-to-transform-bedrock-guardrails-events-into-ocsf-with-cloudwatch
- Publisher: Xcademia — https://www.xcademia.com
- Catalogue index: https://www.xcademia.com/llms-full.txt