AWS Bedrock Delete GuardRails

name: AWS Bedrock Delete GuardRails
id: 7a5e3d62-f743-11ee-9f6e-acde48001122
version: 4
date: '2026-03-10'
author: Bhavin Patel, Splunk
status: production
type: TTP
description: The following analytic identifies attempts to delete AWS Bedrock GuardRails, which are security controls designed to prevent harmful, biased, or inappropriate AI outputs. It leverages AWS CloudTrail logs to detect when a user or service calls the DeleteGuardrail API. This activity is significant as it may indicate an adversary attempting to remove safety guardrails after compromising credentials, potentially to enable harmful or malicious model outputs. Removing guardrails could allow attackers to extract sensitive information, generate offensive content, or bypass security controls designed to prevent prompt injection and other AI-specific attacks. If confirmed malicious, this could represent a deliberate attempt to manipulate model behavior for harmful purposes.
data_source:
    - AWS CloudTrail DeleteGuardrail
search: >-
    `cloudtrail` eventSource=bedrock.amazonaws.com eventName=DeleteGuardrail
    | rename user_name as user
    | stats count min(_time) as firstTime max(_time) as lastTime values(requestParameters.guardrailIdentifier) as guardrailIds by src user user_agent vendor_account vendor_product dest signature vendor_region
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `aws_bedrock_delete_guardrails_filter`
how_to_implement: The Splunk AWS Add-on is required to utilize this data. The search requires AWS CloudTrail logs with Bedrock service events enabled. You must install and configure the AWS App for Splunk (version 6.0.0 or later) and Splunk Add-on for AWS (version 5.1.0 or later) to collect CloudTrail logs from AWS. Ensure the CloudTrail is capturing Bedrock GuardRails management events.
known_false_positives: Legitimate administrators may delete GuardRails as part of normal operations, such as when replacing outdated guardrails with updated versions, cleaning up test resources, or consolidating security controls. Consider implementing an allowlist for expected administrators who regularly manage GuardRails configurations.
references:
    - https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html
    - https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteGuardrail.html
    - https://attack.mitre.org/techniques/T1562/
drilldown_searches:
    - name: View the detection results for - "$user$"
      search: '%original_detection_search% | search user = "$user$"'
      earliest_offset: $info_min_time$
      latest_offset: $info_max_time$
    - name: View risk events for the last 7 days for - "$user$"
      search: '| from datamodel Risk.All_Risk | search normalized_risk_object IN ("$user$") starthoursago=168  | stats count min(_time) as firstTime max(_time) as lastTime values(search_name) as "Search Name" values(risk_message) as "Risk Message" values(analyticstories) as "Analytic Stories" values(annotations._all) as "Annotations" values(annotations.mitre_attack.mitre_tactic) as "ATT&CK Tactics" by normalized_risk_object | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`'
      earliest_offset: $info_min_time$
      latest_offset: $info_max_time$
rba:
    message: User $user$ deleted AWS Bedrock GuardRails $guardrailIds$ from $src$
    risk_objects:
        - field: user
          type: user
          score: 50
    threat_objects:
        - field: src
          type: ip_address
tags:
    analytic_story:
        - AWS Bedrock Security
    asset_type: AWS Account
    mitre_attack_id:
        - T1562.008
    product:
        - Splunk Enterprise
        - Splunk Enterprise Security
        - Splunk Cloud
    security_domain: threat
tests:
    - name: True Positive Test
      attack_data:
        - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/aws_bedrock_delete_guardrails/cloudtrail.json
          sourcetype: aws:cloudtrail
          source: aws_cloudtrail