AWS Bedrock Unauthorized Foundation Model Access Attempt

Identifies failed, access-denied attempts to enable account-level access to an Amazon Bedrock foundation model, 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. A principal that is repeatedly denied when attempting these actions may be a compromised or under-privileged identity probing for the ability to unlock expensive models (LLMjacking) or to establish a durable ability to invoke models. Unlike the companion rule that detects successful model-access grants, this rule surfaces the attempt itself, which is a high-signal indicator of credential boundary-testing even though access was not granted.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/06/04"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2026/06/04"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies failed, access-denied attempts to enable account-level access to an Amazon Bedrock foundation model, either
 11by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model
 12agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can
 13subsequently be invoked. A principal that is repeatedly denied when attempting these actions may be a compromised or
 14under-privileged identity probing for the ability to unlock expensive models (LLMjacking) or to establish a durable
 15ability to invoke models. Unlike the companion rule that detects successful model-access grants, this rule surfaces the
 16attempt itself, which is a high-signal indicator of credential boundary-testing even though access was not granted.
 17"""
 18false_positives = [
 19    """
 20    Access-denied errors can result from benign permission gaps: a newly created role or user whose IAM policy has not
 21    yet been provisioned, automation pipelines running ahead of permission grants, or ML teams experimenting in
 22    non-production accounts during onboarding. Verify that the principal, source IP, and user agent are expected before
 23    escalating. Recurring denials from known onboarding or provisioning workflows can be exempted for specific users or
 24    roles.
 25    """,
 26]
 27from = "now-6m"
 28index = ["logs-aws.cloudtrail-*"]
 29language = "kuery"
 30license = "Elastic License v2"
 31name = "AWS Bedrock Unauthorized Foundation Model Access Attempt"
 32note = """## Triage and analysis
 33
 34> **Disclaimer**:
 35> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 36
 37### Investigating AWS Bedrock Unauthorized Foundation Model Access Attempt
 38
 39Amazon Bedrock exposes account-level "model access" controls that determine which foundation models a principal is allowed to invoke. Granting an entitlement (`PutFoundationModelEntitlement`), submitting a use case for model access (`PutUseCaseForModelAccess`), or creating a foundation-model agreement (`CreateFoundationModelAgreement`, which accepts the model EULA) all unlock a model for subsequent `InvokeModel`/`InvokeModelWithResponseStream` calls.
 40
 41This rule detects Bedrock control-plane calls that enable model access at the account level but were denied (`AccessDenied` / unauthorized). A denial indicates an identity attempting an action it is not permitted to perform, which is a strong signal of boundary-testing by a compromised or under-privileged principal even though no model access was granted.
 42
 43### Possible investigation steps
 44
 45- Identify the principal by reviewing `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`, and determine whether the identity has any legitimate reason to manage Bedrock model access. A denial for an identity that should never touch these APIs is more suspicious than one from an admin with a transient permission gap.
 46- Inspect `aws.cloudtrail.error_code` and `aws.cloudtrail.error_message` to confirm the denial reason, and review `event.action` to determine which model-access action was attempted.
 47- Verify the `source.ip` and `user_agent.original` of the request. An unexpected IP, geolocation, or automation user agent is suspicious.
 48- Confirm the `cloud.account.id` and `cloud.region` are expected for Bedrock usage in your environment.
 49- Correlate with recent activity from the same principal, such as new access key creation, IAM permission changes, or repeated denials across Bedrock/IAM APIs, which can indicate permission enumeration or escalation attempts.
 50- Determine whether the identity later succeeded on the same or related actions (e.g., after acquiring new permissions), and check for subsequent `InvokeModel`/`InvokeModelWithResponseStream` activity.
 51
 52### False positive analysis
 53
 54- Newly provisioned roles/users or infrastructure-as-code pipelines running before model-access permissions are applied may generate transient denials. Validate against change-management records and known provisioning workflows.
 55- ML teams exploring model adoption in sandbox accounts may hit denials; confirm the account and identity context.
 56
 57### Response and remediation
 58
 59- If the attempt is unexpected, treat the identity as potentially compromised: disable or rotate the credentials (`aws.cloudtrail.user_identity.access_key_id`) and review the actor's recent activity.
 60- Review all Bedrock and IAM activity from the same identity in the surrounding window for successful access grants, permission changes, or other persistence attempts.
 61- Review and constrain IAM permissions so that only approved principals can call Bedrock model-access APIs, and alert on both denied and successful calls.
 62- Implement preventative guardrails (SCPs, IAM conditions) to limit which principals and models can be enabled.
 63"""
 64references = [
 65    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutFoundationModelEntitlement.html",
 66    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html",
 67    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateFoundationModelAgreement.html"
 68]
 69risk_score = 21
 70rule_id = "3d2e8c90-5be7-4a57-9de4-58be75af933f"
 71severity = "low"
 72tags = [
 73    "Domain: Cloud",
 74    "Domain: LLM",
 75    "Data Source: AWS",
 76    "Data Source: AWS CloudTrail",
 77    "Data Source: Amazon Web Services",
 78    "Data Source: Amazon Bedrock",
 79    "Use Case: Threat Detection",
 80    "Tactic: Persistence",
 81    "Resources: Investigation Guide",
 82]
 83timestamp_override = "event.ingested"
 84type = "query"
 85
 86query = '''
 87data_stream.dataset: "aws.cloudtrail"
 88    and event.provider: "bedrock.amazonaws.com"
 89    and event.action: (
 90        "PutFoundationModelEntitlement" or
 91        "PutUseCaseForModelAccess" or
 92        "CreateFoundationModelAgreement"
 93    )
 94    and event.outcome: "failure"
 95    and aws.cloudtrail.error_code: (
 96        "AccessDenied" or
 97        "AccessDeniedException"
 98    )
 99'''
100
101[[rule.threat]]
102framework = "MITRE ATT&CK"
103
104[[rule.threat.technique]]
105id = "T1098"
106name = "Account Manipulation"
107reference = "https://attack.mitre.org/techniques/T1098/"
108
109[rule.threat.tactic]
110id = "TA0003"
111name = "Persistence"
112reference = "https://attack.mitre.org/tactics/TA0003/"
113
114[rule.investigation_fields]
115field_names = [
116    "@timestamp",
117    "user.name",
118    "user_agent.original",
119    "source.ip",
120    "aws.cloudtrail.user_identity.arn",
121    "aws.cloudtrail.user_identity.access_key_id",
122    "event.action",
123    "event.outcome",
124    "aws.cloudtrail.error_code",
125    "cloud.account.id",
126    "cloud.region",
127    "aws.cloudtrail.request_parameters",
128]

Triage and analysis

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

Investigating AWS Bedrock Unauthorized Foundation Model Access Attempt

Amazon Bedrock exposes account-level "model access" controls that determine which foundation models a principal is allowed to invoke. Granting an entitlement (PutFoundationModelEntitlement), submitting a use case for model access (PutUseCaseForModelAccess), or creating a foundation-model agreement (CreateFoundationModelAgreement, which accepts the model EULA) all unlock a model for subsequent InvokeModel/InvokeModelWithResponseStream calls.

This rule detects Bedrock control-plane calls that enable model access at the account level but were denied (AccessDenied / unauthorized). A denial indicates an identity attempting an action it is not permitted to perform, which is a strong signal of boundary-testing by a compromised or under-privileged principal even though no model access was granted.

Possible investigation steps

  • Identify the principal by reviewing aws.cloudtrail.user_identity.arn and aws.cloudtrail.user_identity.access_key_id, and determine whether the identity has any legitimate reason to manage Bedrock model access. A denial for an identity that should never touch these APIs is more suspicious than one from an admin with a transient permission gap.
  • Inspect aws.cloudtrail.error_code and aws.cloudtrail.error_message to confirm the denial reason, and review event.action to determine which model-access action was attempted.
  • Verify the source.ip and user_agent.original of the request. An unexpected IP, geolocation, or automation user agent is suspicious.
  • Confirm the cloud.account.id and cloud.region are expected for Bedrock usage in your environment.
  • Correlate with recent activity from the same principal, such as new access key creation, IAM permission changes, or repeated denials across Bedrock/IAM APIs, which can indicate permission enumeration or escalation attempts.
  • Determine whether the identity later succeeded on the same or related actions (e.g., after acquiring new permissions), and check for subsequent InvokeModel/InvokeModelWithResponseStream activity.

False positive analysis

  • Newly provisioned roles/users or infrastructure-as-code pipelines running before model-access permissions are applied may generate transient denials. Validate against change-management records and known provisioning workflows.
  • ML teams exploring model adoption in sandbox accounts may hit denials; confirm the account and identity context.

Response and remediation

  • If the attempt is unexpected, treat the identity as potentially compromised: disable or rotate the credentials (aws.cloudtrail.user_identity.access_key_id) and review the actor's recent activity.
  • Review all Bedrock and IAM activity from the same identity in the surrounding window for successful access grants, permission changes, or other persistence attempts.
  • Review and constrain IAM permissions so that only approved principals can call Bedrock model-access APIs, and alert on both denied and successful calls.
  • Implement preventative guardrails (SCPs, IAM conditions) to limit which principals and models can be enabled.

References

Related rules

to-top