A Lambda transform lands blocked prompt injections in the same Athena catalog as CloudTrail

A guardrail intervention lands in two places, and neither is where a SOC analyst works. Bedrock publishes the telemetry to CloudWatch metrics and to model invocation logs for operational monitoring ^[1]. Left there, the interventions sit as per-Region metrics and entries in raw invocation logs, separate from the identity, network and audit data the security team already uses ^[2]. The detail is in the logs, where guardrail traces arrive as JSON in a Bedrock-specific shape instead of a normalized security schema ^[3].

The pipeline captures the intervention events from the model invocation logs, transforms them into OCSF Detection Finding records in a Lambda function, and writes them to the CloudWatch unified data store ^[4]. That store launched in December 2025 and consolidates operational, security and compliance data from AWS services and third-party sources ^[5]. Analysts query it with Athena or CloudWatch Logs Insights ^[6].

The payoff is in the schema. After transformation, guardrail findings share the same field structure as the other security sources and sit in the same catalog as CloudTrail events and VPC Flow Logs, so one Athena query answers the three investigative questions AWS sets out ^[7].

Those questions are the bar for whether the mapping is worth building. Which accounts trigger the most interventions, and do those same accounts also show failed API calls or privilege changes in IAM ^[8]. Do prompt injection attempts line up with source IPs that also appear in VPC Flow Logs ^[9]. How does the organization-wide violation trend compare against a baseline from 30 days ago ^[10]. The first and third are aggregations over individual records, which per-Region counters cannot produce ^[2]. The second is a join, and a join only pays off if the OCSF record carries an address that also shows up in flow logs. Where Bedrock is called by an application role on behalf of end users, what address the trace actually contains decides whether the join pays.

GuardDuty complicates the build decision. Its AI Protection feature analyzes CloudTrail data events from Bedrock and produces managed threat findings, including a direct prompt injection finding and anomalous model invocation findings ^[11]. The post calls it "a complementary managed detection layer for AWS Bedrock activity" ^[12] and positions the pipeline as the thing that captures the raw intervention records, normalizes them, and lands them for your own cross-source correlation and long-term trend analysis alongside those findings ^[13]. The two paths read different inputs: GuardDuty reads CloudTrail data events, the pipeline reads model invocation logs ^[11][4].

So the question before anyone writes the Lambda is which investigations need the intervention record itself. The per-account ranking and the 30-day baseline comparison do ^[8][10]. Whether a prompt injection attempt happened at all does not, because GuardDuty already emits that finding ^[11]. Guardrails also intervene on harmful content, off-topic queries and PII ^[15], so the record volume you are normalizing is wider than the prompt injection subset the security team came for.

AWS's own framing sets the standard the rest of the design has to meet: the post says that when a guardrail blocks a prompt injection or redacts sensitive data, the intervention carries investigative value comparable to a failed sign-in or a network intrusion alert ^[14].