EXPLORE DETECTIONS
AWS Backup Recovery Point Deleted
Identifies deletion of an AWS Backup recovery point via DeleteRecoveryPoint. A recovery point is a stored backup of a protected resource (EBS, RDS, DynamoDB, EFS, S3, and others). Deleting recovery points removes the ability to restore the associated data and is a core anti-recovery technique used in ransomware and data-destruction attacks to ensure victims cannot recover without paying or rebuilding. Routine lifecycle expirations are performed by the AWS Backup service itself; deletion by a non-service principal is rare and should be reviewed.
AWS Backup Vault Deleted or Vault Lock Removed
Identifies deletion of an AWS Backup vault or removal of its Vault Lock configuration via DeleteBackupVault or DeleteBackupVaultLockConfiguration. A backup vault stores recovery points, and Vault Lock enforces WORM (write-once, read-many) immutability that prevents recovery points from being deleted before their retention expires. Removing the lock defeats the primary control designed to stop ransomware from destroying backups, and deleting the vault removes the backup container entirely. Both actions are strong anti-recovery signals and are rare in normal operations.
AWS Bedrock Agent Created by IAM User or Root
Identifies AWS Bedrock Agent creation performed directly by an IAM user or the root account. Bedrock Agents are autonomous AI systems that execute multi-step tasks, invoke Lambda action groups to call external APIs, and query knowledge bases. Adversaries with access to an AWS account can create rogue agents configured to exfiltrate data via action group Lambda functions, pivot to other services, or act as a persistent AI-driven command-and-control channel. This rule is scoped to IAMUser and Root identity types — AssumedRole sessions (which represent automated CI/CD pipelines and SSO-federated engineers) are excluded to avoid global false positives from legitimate deployment automation that varies widely across customer environments.
AWS Bedrock Agent or Action Group Manipulation
Detects modification of deployed Amazon Bedrock agents and their action groups, collaborators, or aliases via the Bedrock Agent control plane. Adversaries with access to an AWS account can tamper with an existing, trusted agent by altering its instructions (UpdateAgent), adding or changing action groups that wire the agent to Lambda functions or APIs (CreateAgentActionGroup, UpdateAgentActionGroup), attaching or modifying collaborators (AssociateAgentCollaborator, UpdateAgentCollaborator), or repointing an alias to a tampered version (CreateAgentAlias, UpdateAgentAlias). A PrepareAgent call is required to make a tampered configuration live. By implanting malicious behavior into an agent that legitimate users continue to invoke, an attacker can maintain durable access through a trusted component. Creation of brand-new agents (CreateAgent) is intentionally excluded as lower-signal activity.
AWS Bedrock AgentCore Runtime Prompt Containing Credentials
Identifies prompts sent to an Amazon Bedrock AgentCore runtime that contain AWS access key identifiers (AKIA long-term or ASIA temporary/STS), Amazon Bedrock API keys (ABSK bearer tokens), or PEM-encoded private keys. The runtime application logs record the caller-supplied prompt; credentials embedded in a prompt are exposed to the model provider, persisted in observability logs, and may be returned in completions or used by downstream tools. This commonly indicates accidental secret leakage by a user or application, or an attempt to stage credentials for misuse through the agent. Secrets should never be passed to an agent in clear text.
AWS Bedrock AgentCore Runtime Prompt Targeting Credentials or Instance Metadata
Identifies prompts sent to an Amazon Bedrock AgentCore runtime that attempt to harvest credentials or coerce the agent into exfiltrating data. The runtime application logs capture the caller-supplied prompt; this rule flags prompts that reference the cloud instance metadata service (169.254.169.254, the ECS task metadata address, or the "latest/meta-data" / "security-credentials" paths), prompts that name AWS access or secret keys directly, and prompt-injection or jailbreak language ("ignore previous instructions", "developer mode", "do anything now") combined with intent to reveal secrets, system prompts, or send data to an external endpoint. Asking an agent to read instance metadata credentials or to exfiltrate secrets is rarely legitimate and indicates an attempt to weaponize the agent for credential theft, even when the model refuses the request.
AWS Bedrock API Key Phantom User Activity Outside Bedrock
Identifies an Amazon Bedrock API key phantom user (an IAM user whose name starts with "BedrockAPIKey-") acting as the caller of a non-Bedrock API request, such as IAM, STS, EC2, VPC, or KMS calls. These users are provisioned by AWS to back a Bedrock bearer token and carry the AmazonBedrockLimitedAccess managed policy, which also grants IAM, VPC, and KMS reconnaissance. A phantom user performing activity outside of Bedrock indicates its credentials are being used beyond their intended scope, which is the privilege-escalation path realized: an attacker who created standard IAM access keys for the phantom user is now using them for reconnaissance or lateral movement outside the Bedrock authentication boundary.
AWS Bedrock API Key Used for Destructive or Anti-Recovery Action
Identifies an Amazon Bedrock API key (bearer token) being used to perform a destructive or anti-recovery control-plane action, such as deleting a guardrail, deleting a custom or imported model, removing provisioned throughput, or disabling model invocation logging. Bedrock API keys are bearer credentials intended for model invocation (InvokeModel, Converse); using one to delete Bedrock resources or disable logging is inconsistent with that purpose and is characteristic of LLMjacking or sabotage following key theft. Every Bedrock API key call is identifiable in CloudTrail by "additionalEventData.callWithBearerToken" being true. The rule matches regardless of outcome, because a destructive attempt via a bearer token is suspicious even when denied.
AWS Bedrock Automated Reasoning Safety Policy Tampering
Detects deletion or modification of AWS Bedrock Automated Reasoning policies via the DeleteAutomatedReasoningPolicy, UpdateAutomatedReasoningPolicy, or UpdateAutomatedReasoningPolicyAnnotations CloudTrail actions. Automated Reasoning policies are a Bedrock safety and validation control that constrains model outputs against formal rules. An adversary who deletes a policy or alters the policy definition or its annotations weakens an enforced output-validation defense, potentially allowing unsafe or non-compliant model responses to pass unchecked. Benign build, test-workflow, and test-case CRUD operations are intentionally excluded as they have no coherent abuse path.
AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User
Identifies multiple successive failed attempts to use denied model resources within AWS Bedrock. This could indicated attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs.
AWS Bedrock Detected Multiple Validation Exception Errors by a Single User
Identifies multiple validation exeception errors within AWS Bedrock. Validation errors occur when you run the InvokeModel or InvokeModelWithResponseStream APIs on a foundation model that uses an incorrect inference parameter or corresponding value. These errors also occur when you use an inference parameter for one model with a model that doesn't have the same API parameter. This could indicate attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs.
AWS Bedrock Foundation Model Access Enabled or Entitlement Granted
Identifies when access to an Amazon Bedrock foundation model is enabled at the account level, either by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently be invoked. Adversaries or a compromised principal may enable model access to abuse expensive models (LLMjacking), to establish a durable ability to invoke models within the account, or to bypass organizational controls. This activity is distinct from changes to a resource-based model invocation policy and is identified by the Bedrock control-plane API calls that grant model entitlements and agreements.
AWS Bedrock Foundation Model Enumeration Followed by Invocation via Long-Term Key
Detects when an AWS principal using long-term IAM user credentials (AKIA* access key) enumerates available Bedrock foundation models and then invokes a model within the same 15-minute window. Most legitimate Bedrock workloads run under IAM roles with short-lived credentials; the combination of model enumeration followed by direct model invocation from a long-term IAM user key is unusual in production environments and consistent with an adversary using stolen credentials to discover and exploit available AI model capabilities. This pattern is associated with LLMjacking attacks where threat actors abuse compromised cloud credentials to run high-volume or high-cost model inference at the account owner's expense.
AWS Bedrock Guardrail Deleted or Weakened
Detects deletion, weakening, or version management of AWS Bedrock guardrails via the DeleteGuardrail, UpdateGuardrail, DeleteEnforcedGuardrailConfiguration, or PutEnforcedGuardrailConfiguration APIs. Bedrock guardrails enforce content, topic, word, and sensitive-information policies on model invocations. Deleting a guardrail, loosening its policies, removing or overwriting the organization-enforced guardrail configuration, or creating a new version to enforce a weakened configuration allows an adversary to bypass these protections — the cloud control-plane equivalent of disabling a security tool. This activity should be validated against approved change management and the responsible identity.
AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request
Identifies multiple violations of AWS Bedrock guardrails within a single request, resulting in a block action, increasing the likelihood of malicious intent. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system.
AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session
Identifies multiple violations of AWS Bedrock guardrails by the same user in the same account over a session. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system.
AWS Bedrock High-Frequency Single-Model Inference API Probing
Identifies an AWS principal performing a high volume of Amazon Bedrock inference API calls against a single model within a short window. Membership inference attacks require hundreds to thousands of statistically similar queries whose prompts and responses are intentionally content-benign, making guardrail- and content-based rules ineffective. This rule detects the high-frequency single-model probing pattern that precedes membership inference and related exfiltration via the inference API. It is a behavioral / volumetric precursor: it does not observe model confidence scores and a fixed call-count threshold only catches the loud variant, so paced, low-and-slow, or credential-distributed probing will evade it. Definitive membership inference detection requires ML anomaly analysis over per-entity inference-rate and response-distribution baselines.
AWS Bedrock Invocations without Guardrails Detected by a Single User Over a Session
Identifies multiple AWS Bedrock executions in a one minute time window without guardrails by the same user in the same account over a session. Multiple consecutive executions implies that a user may be intentionally attempting to bypass security controls, by not routing the requests with the desired guardrail configuration in order to access sensitive information, or possibly exploit a vulnerability in the system.
AWS Bedrock Knowledge Base or RAG Data Source Tampering
Detects control-plane mutations to AWS Bedrock knowledge bases and their backing RAG data sources via CloudTrail. An adversary with access to Bedrock Agent APIs can poison the corpus that RAG-enabled models treat as authoritative by ingesting attacker-controlled documents (IngestKnowledgeBaseDocuments, StartIngestionJob), deleting legitimate documents (DeleteKnowledgeBaseDocuments), or repointing/altering the data source itself (CreateDataSource, UpdateDataSource, DeleteDataSource, UpdateKnowledgeBase). Because downstream applications and users trust model answers grounded in this stored data, tampering with the corpus is a stored data manipulation that can drive misinformation, fraud, or manipulated decisions at inference time. This is a New Terms rule that looks for the first time a given identity ARN performs one of these knowledge base or data source mutations within the history window.
AWS Bedrock Model Invocation Logging Disabled or Modified
Detects when an AWS Bedrock model invocation logging configuration is deleted or overwritten via the DeleteModelInvocationLoggingConfiguration or PutModelInvocationLoggingConfiguration API calls. Model invocation logging is the source that feeds the logs-aws_bedrock.invocation-* dataset relied upon by all data-plane Bedrock detections. An adversary who has gained access to a Bedrock environment can blind defenders by deleting this configuration, or by using the Put API to redirect logs to an attacker-controlled or non-monitored S3 bucket or CloudWatch log group. Because this single control-plane action can neutralize the entire data-plane detection stack, it is a high-value evasion technique that should be validated against expected administrative change activity.
AWS Bedrock Model Prompt or Completion Containing Credentials
Identifies an Amazon Bedrock model invocation whose prompt or completion contains an AWS access key identifier (AKIA long-term or ASIA temporary/STS, followed by 16 characters), an Amazon Bedrock API key (ABSK bearer token), or a PEM private-key block. Credentials in the model input mean an application or user is sending secrets to the model, exposing them to invocation logging, the model provider, and prompt history; credentials in the model output mean the model is emitting secrets, which can result from training-data leakage, poisoned context, or a prompt-injection-driven exfiltration attempt. Either case is a credential-exposure event that warrants immediate rotation of the affected secret.
AWS Bedrock Provisioned Model Throughput Tampering
Detects creation, modification, or deletion of AWS Bedrock Provisioned Model Throughput via the CreateProvisionedModelThroughput, UpdateProvisionedModelThroughput, and DeleteProvisionedModelThroughput APIs. Provisioned Throughput reserves dedicated, billed model capacity for Amazon Bedrock. An adversary who scales this capacity up can drive large, unauthorized cost (cloud resource/bill hijacking), while deleting reserved throughput can cause denial of service to production workloads that depend on that committed capacity. These control-plane changes should be validated against approved capacity-planning and change-management processes.
AWS Bedrock Resource-Based Policy Modified or Deleted
Detects modification or deletion of resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. An adversary may attach a resource policy granting an external or unexpected principal access to a Bedrock resource to establish persistence or enable cross-account access, or may delete an existing policy to weaken access controls. These changes should be validated for principal ownership and least-privilege intent.
AWS Bedrock Third-Party or External Knowledge Base Associated to Agent
Detects when an Amazon Bedrock agent is associated with, or updated to use, a knowledge base via the AssociateAgentKnowledgeBase, or UpdateAgentKnowledgeBase API actions. Bedrock agents consume knowledge base (RAG) content as trusted context for the model. By wiring an agent to an externally controlled or third-party knowledge base, or by swapping in an attacker-controlled knowledge base, an adversary can redraw the agent's trust boundary toward an untrusted source. This is a software-supply-chain compromise and an indirect prompt-injection delivery vector: poisoned or adversarial content served from the associated knowledge base is treated as authoritative by the agent. Validate that the associated knowledge base, and any underlying data source, is owned and controlled by your organization.