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.

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 when access to an Amazon Bedrock foundation model is enabled at the account level, either by granting a
 11foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement
 12(accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently
 13be invoked. Adversaries or a compromised principal may enable model access to abuse expensive models (LLMjacking), to
 14establish a durable ability to invoke models within the account, or to bypass organizational controls. This activity is
 15distinct from changes to a resource-based model invocation policy and is identified by the Bedrock control-plane API
 16calls that grant model entitlements and agreements.
 17"""
 18false_positives = [
 19    """
 20    Cloud administrators and machine-learning teams routinely enable model access, submit use cases, and accept model
 21    end-user license agreements (EULAs) during account onboarding or when adopting a new foundation model. Verify that
 22    the principal, source IP, and user agent are expected and that the change aligns with a known onboarding or
 23    provisioning activity before escalating. If this activity is expected and authorized for specific principals,
 24    consider adding exceptions for those users or roles.
 25    """,
 26]
 27from = "now-6m"
 28index = ["logs-aws.cloudtrail-*"]
 29language = "kuery"
 30license = "Elastic License v2"
 31name = "AWS Bedrock Foundation Model Access Enabled or Entitlement Granted"
 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 Foundation Model Access Enabled or Entitlement Granted
 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
 41Adversaries who gain access to a privileged principal may enable model access to abuse high-cost models (LLMjacking), to maintain a durable capability to invoke models, or to circumvent organizational guardrails on which models are usable.
 42
 43This rule detects successful Bedrock control-plane API calls that enable model access at the account level. It is distinct from changes to a resource-based model invocation policy.
 44
 45### Possible investigation steps
 46
 47- Identify the principal by reviewing `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`, and determine whether the identity is a human user, role, or service account that is expected to manage Bedrock model access.
 48- Review `event.action` to determine which model-access action was taken, and examine `aws.cloudtrail.request_parameters` to identify the specific foundation model, model ID, or use case involved.
 49- Verify the `source.ip` and `user_agent.original` of the request. Console-driven onboarding differs from programmatic SDK/CLI calls; an unexpected IP, geolocation, or automation user agent is suspicious.
 50- Confirm the `cloud.account.id` and `cloud.region` are expected for Bedrock usage in your environment, and whether model access is normally enabled in that region.
 51- Correlate with recent activity from the same principal, such as new access key creation, IAM permission changes, or other Bedrock control-plane calls, to determine whether this is part of a broader compromise.
 52- Check for subsequent `InvokeModel`/`InvokeModelWithResponseStream` activity from the same principal or account, especially high-volume invocations that could indicate model abuse (LLMjacking).
 53- Contact the resource owner to confirm whether enabling this model access was planned and authorized.
 54
 55### False positive analysis
 56
 57- Legitimate administrators and ML teams enable model access and accept EULAs during account onboarding or when adopting new foundation models. Validate the change against change-management records and known provisioning workflows.
 58- Infrastructure-as-code or automation pipelines may enable model access programmatically; confirm the automation identity and source are expected.
 59
 60### Response and remediation
 61
 62- If the activity is unauthorized, revoke the model entitlement/agreement and remove model access for the affected model.
 63- Disable or rotate the credentials (`aws.cloudtrail.user_identity.access_key_id`) associated with the principal that performed the action.
 64- Review and constrain IAM permissions so that only approved principals can call Bedrock model-access APIs.
 65- Investigate for any model invocations that occurred after access was granted and assess potential cost impact and data exposure.
 66- Implement preventative guardrails (SCPs, IAM conditions) to limit which principals and models can be enabled, and add monitoring for Bedrock control-plane changes.
 67"""
 68references = [
 69    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutFoundationModelEntitlement.html",
 70    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html",
 71    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateFoundationModelAgreement.html"
 72]
 73risk_score = 47
 74rule_id = "aed4b9d5-f853-40cf-8489-4fdcff03e272"
 75severity = "medium"
 76tags = [
 77    "Domain: Cloud",
 78    "Domain: LLM",
 79    "Data Source: AWS",
 80    "Data Source: AWS CloudTrail",
 81    "Data Source: Amazon Web Services",
 82    "Data Source: Amazon Bedrock",
 83    "Use Case: Threat Detection",
 84    "Tactic: Persistence",
 85    "Resources: Investigation Guide",
 86]
 87timestamp_override = "event.ingested"
 88type = "query"
 89
 90query = '''
 91data_stream.dataset: "aws.cloudtrail"
 92    and event.provider: "bedrock.amazonaws.com"
 93    and event.action: (
 94        "PutFoundationModelEntitlement" or
 95        "PutUseCaseForModelAccess" or
 96        "CreateFoundationModelAgreement"
 97    )
 98    and event.outcome: "success"
 99'''
100
101
102[[rule.threat]]
103framework = "MITRE ATT&CK"
104
105[[rule.threat.technique]]
106id = "T1098"
107name = "Account Manipulation"
108reference = "https://attack.mitre.org/techniques/T1098/"
109
110[rule.threat.tactic]
111id = "TA0003"
112name = "Persistence"
113reference = "https://attack.mitre.org/tactics/TA0003/"
114
115[rule.investigation_fields]
116field_names = [
117    "@timestamp",
118    "user.name",
119    "user_agent.original",
120    "source.ip",
121    "aws.cloudtrail.user_identity.arn",
122    "aws.cloudtrail.user_identity.access_key_id",
123    "event.action",
124    "event.outcome",
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 Foundation Model Access Enabled or Entitlement Granted

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.

Adversaries who gain access to a privileged principal may enable model access to abuse high-cost models (LLMjacking), to maintain a durable capability to invoke models, or to circumvent organizational guardrails on which models are usable.

This rule detects successful Bedrock control-plane API calls that enable model access at the account level. It is distinct from changes to a resource-based model invocation policy.

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 is a human user, role, or service account that is expected to manage Bedrock model access.
  • Review event.action to determine which model-access action was taken, and examine aws.cloudtrail.request_parameters to identify the specific foundation model, model ID, or use case involved.
  • Verify the source.ip and user_agent.original of the request. Console-driven onboarding differs from programmatic SDK/CLI calls; 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, and whether model access is normally enabled in that region.
  • Correlate with recent activity from the same principal, such as new access key creation, IAM permission changes, or other Bedrock control-plane calls, to determine whether this is part of a broader compromise.
  • Check for subsequent InvokeModel/InvokeModelWithResponseStream activity from the same principal or account, especially high-volume invocations that could indicate model abuse (LLMjacking).
  • Contact the resource owner to confirm whether enabling this model access was planned and authorized.

False positive analysis

  • Legitimate administrators and ML teams enable model access and accept EULAs during account onboarding or when adopting new foundation models. Validate the change against change-management records and known provisioning workflows.
  • Infrastructure-as-code or automation pipelines may enable model access programmatically; confirm the automation identity and source are expected.

Response and remediation

  • If the activity is unauthorized, revoke the model entitlement/agreement and remove model access for the affected model.
  • Disable or rotate the credentials (aws.cloudtrail.user_identity.access_key_id) associated with the principal that performed the action.
  • Review and constrain IAM permissions so that only approved principals can call Bedrock model-access APIs.
  • Investigate for any model invocations that occurred after access was granted and assess potential cost impact and data exposure.
  • Implement preventative guardrails (SCPs, IAM conditions) to limit which principals and models can be enabled, and add monitoring for Bedrock control-plane changes.

References

Related rules

to-top