Using Splunk to Monitor AWS Bedrock Claude Security

AWS Bedrock brings foundation models like Claude directly into enterprise infrastructure, and with that comes a security monitoring gap that most organizations are not prepared for. Unlike traditional logs, AI model invocations carry a unique combination of signals (who called the model, with what instructions, using which tools and how much data came back) which is novel to existing SIEM content in terms of monitoring and detection.

Left unmonitored, Bedrock deployments become a blind spot where adversaries can abuse agentic pipelines, exfiltrate data through model outputs, or execute shell commands through AI assisted toolchains without triggering a single alert. This blog documents the end-to-end process of ingesting AWS Bedrock Claude model invocation logs into Splunk and building a detection library grounded in real production data.

Pipeline Architecture

The first step is to get logs into Splunk. AWS Bedrock model invocation logging is disabled by default and must be explicitly enabled per region. Following AWS documentation, navigate to the AWS Console, select Bedrock, go to settings and enable model invocation under the Model invocation logging section. You will be prompted to select which data to log (enable for both text and image modalities to ensure full coverage) and choose your logging destination.

For this deployment, engineering configured S3 as the logging destination, which is the correct choice for a production security monitoring pipeline. S3 receives the complete json record for every invocation regardless of payload size, stored as gzipped JSON objects under a path. Like in the following example.

s3://your-bucket/AWSLogs/<accountId>/BedrockModelInvocationLogs/<region>/<year>/<month>/<day>/

The S3 bucket policy must explicitly allow Bedrock to write to it: The following is the minimum required policy.

Splunk Add-on for AWS S3 Input Configuration

With logs landing in S3, the next step is pulling them into Splunk using the Splunk Add-on for Amazon Web Services. The recommended approach for S3 ingestion is SQS-based notification. S3 publishes an event to an SQS queue each time a new log object is written, and Splunk polls the queue rather than scanning the entire bucket.

IAM role and inputs used by the Splunk Add-on must be configured.

For this research, we created an index for AWS Bedrock Claude invocation logs. For sourcetype, Bedrock invocation logs arrive as JSON. You can also modify props.conf if you wish to clean JSON parsing and correct timestamp extraction. For our research, json_no_timestamp was able to break the events correctly.

One important note on the log format: Bedrock invocation logs can appear in different structural variants depending on which runtime API was used. Non-streaming calls made through InvokeModel typically log a standard nested JSON response under output.outputBodyJson. Streaming calls made through InvokeModelWithResponseStream—commonly used by Claude Code and many agentic frameworks—can log the response as multiple streamed chunk/delta objects inside output.outputBodyJson rather than a single response object. This distinction matters because detection logic that assumes one fixed output path may miss streamed Claude output, tool-use deltas, or final message content. Field extractions should handle both the non-streaming object form and the streaming chunk/delta array form.

Common Log Structure

Every Bedrock Invocation log record contains the following top-level fields regardless of API type:

Key Security-Relevant Fields

AWS Bedrock supports multiple API methods for calling Claude, and each one produces a slightly different log structure in S3. The two most common are InvokeModel, which returns the complete response as a single JSON object making field extraction straightforward, and InvokeModelWithResponseStream, which streams the response back in small chunks stored as an array of delta objects that must be reassembled to get the full content. Understanding which API your applications are using is the first step before any detection logic, because the same field like a tool name or token count will be in a completely different location depending on which method generated the log. In our research we used InvokeModelWithResponseStream.

Working with Data

When monitoring AWS Bedrock, one of the first things that can be noticed is that not all identities behave the same way. Automated identities like service accounts, Lambda execution roles, and agentic pipelines operate continuously around the clock as part of defined workflows. These identities will naturally generate high volumes of model invocations at all hours, invoke tools repeatedly as part of pipeline logic, and produce variable token counts depending on what they are processing. These activities cannot be treated the same as human-driven sessions, and this may flood detections with noise.

Human identities on the other hand are identifiable by email addresses or named session tokens in the identitiy.arn field and should follow predictable hours, especially working hours, specific use cases and likely a defined set of tools. When a human session deviates from that pattern, for example invoking shell execution tools, writing files or fetching remote content through an AI model, it should carry more weight as a security signal than in comparison to an automated pipeline.

One of the things that are also very relevant is the tool enumeration across all model invocations, which is fundamental to understanding agentic Bedrock environments.

As seen in the above graph, we can identify several tools that can reveal the nature of the platform operations, whether is a document retrieval assistant, a code execution environment, a workflow automation tool, or a combination of many.

Tools that retrieve information from internal systems represent a data exposure risk if abused. Tools that write or modify files represent a persistent risk. Tools that execute shell command or make outbound network calls represent the highest risk. The combination of shell execution and file write tools in the same agentic environment means Claude can be directed to run commands, capture output, and write results to disk in a single session.

Detection Use Cases

The detections showcased in this blog span three broad security concerns—identity and behavioral analytics, agentic tool abuse, and data exposure—each of which maps to a distinct way that AI infrastructure can be misused or compromised. As organizations expand their Bedrock deployments beyond simple question-and-answer interfaces into fully agentic pipelines with access to internal systems, code execution environments, and sensitive data stores, these detection categories will remain relevant regardless of which specific models, tools, or workflows are in use.

AWS Bedrock Claude High Risk Filesystem and Execution Tool Invocation detects when high risk tools such as shell execution, file writes, network calls, and filesystem reads are invoked through Claude in an AWS Bedrock agentic session. The detection classifies invoking identities as automated or human driven and applies risk scoring based on dangerous tool combinations—shell execution paired with file writes indicates a possible execution and persistence chain, while shell execution paired with outbound network calls indicates a possible download and execute pattern. Validated against production Bedrock invocation logs, this detection surfaces both automated pipeline activity and direct human-driven sessions invoking dangerous tool combinations through an AI model, with MITRE ATT&CK mappings covering command and scripting interpreter execution, ingress tool transfer, data manipulation, and file and directory discovery.

The detection results above reveal two distinct risk profiles within the same Bedrock environment. The first involves automated workflow identities invoking network and filesystem tools as part of pipeline activity—a pattern that while expected in scope warrants continuous monitoring given the capability for outbound data transfer. The second and higher severity finding involves human identities directly invoking shell execution and file write tools through Claude, a combination that represents a complete execution and persistence chain operating through an AI model and requires investigation.

AWS Bedrock Claude Sensitive Data in Prompts detects when input prompts sent to Claude contain patterns consistent with sensitive data such as credentials, API keys, personally identifiable information, or internal secrets that should never be passed directly into a model invocation. This detection operates against the input.inputBodyJson field in the Bedrock invocation log and uses regex pattern matching to flag prompts containing high risk content before that content is potentially echoed back in a model response, logged in a third party system, or exposed through an agentic tool chain. Beyond the immediate data exposure risk, sensitive data appearing in prompts is also an indicator of poor application design or a misconfigured integration that is inadvertently leaking secrets into AI infrastructure that may be outside the organization's normal data governance boundaries.

The detection results above expose a serious data hygiene problem across multiple human identities operating in the same Bedrock environment—prompts contain cleartext database passwords, API tokens, AWS access keys, and session credentials being passed directly into Claude as part of command output and shell history. What makes this particularly concerning is that these are not accidental pastes but the byproduct of agentic sessions where Claude is executing commands and receiving their output back as context, meaning credentials are flowing through the model invocation log, being stored in S3, and potentially being processed by the model in subsequent turns. Each of these events represents both a secrets exposure incident and a detection engineering opportunity—the presence of credential patterns in prompt text is a high-fidelity signal that an agentic session has access to sensitive infrastructure and is operating without secrets management controls in place.

AWS Bedrock Claude Hostile Prompt a detection that flags prompt content containing language patterns consistent with adversarial intent, including instructions to ignore previous directives, assume unrestricted personas or bypass safety controls.

The Splunk Cisco STRT team is releasing other detections as well, which also include the following use cases and more. They can all be found at research.splunk.com.

AWS Bedrock Claude Excessive Use of Tokens a detection that identifies identities generating statistically anomalous token volumes relative to their own historical baselines.

AWS Bedrock Claude Possible Prompt Injection an analytic targeting the identification of prompts that contain embedded instructions inconsistent with application’s defined system prompt, a pattern consistent with indirect prompt injection where malicious content retrieved from an external source attempt to hijack the model’s behavior.

AWS Bedrock Claude Cross Region Possible Inference Abuse detects when model invocations are routed through AWS regions that differ from the identity’s expected or approved operating region, which may indicate an attempt to bypass regional guardrails, data residency controls, or service control policies applied at the organizational level. Cross region inference is a legitimate AWS Bedrock feature through inference profiles, but unexpected region combinations, particularly where the invoking identity has no prior history in the destination region, represent a policy violation risk and a potential indicator of credential misuse or unauthorized model access.

Conclusion

In this blog we explored the critical importance of security monitoring for AWS Bedrock Claude deployments, walking through the full pipeline from S3 log ingestion to production-validated detections built against real agentic traffic. By establishing visibility into who is calling the model, what tools they are invoking, and how much data is moving through each session, security teams can begin to draw a meaningful boundary around AI infrastructure that is increasingly embedded in the heart of enterprise operations. The detections presented here are a starting point—grounded in the reality that agentic AI deployments are not static targets but expanding ones, growing in scope, capability, and organizational reach with every new integration, every new tool, and every new identity granted access to a foundation model.