AWS Bedrock High Tool-Request Call Volume

A machine learning job has detected an unusually high number of tool-requesting Amazon Bedrock model responses within 15 minutes for a caller, compared with that caller's own history. High call volume can indicate repeated over-invocation or loop amplification by an AI agent (OWASP ASI02, Tool Misuse and Exploitation) and can lead to resource exhaustion and cost. The volume counts responses that requested tools, not confirmed tool executions.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/10/23"
  3integration = ["security_ai", "aws_bedrock"]
  4maturity = "production"
  5min_stack_comments = "Detection rules for the security_ai integration package are supported in v9.6.0 and above"
  6min_stack_version = "9.6.0"
  7updated_date = "2026/11/06"
  8
  9[rule]
 10anomaly_threshold = 50
 11author = ["Elastic"]
 12description = """
 13A machine learning job has detected an unusually high number of tool-requesting Amazon Bedrock model responses within 15
 14minutes for a caller, compared with that caller's own history. High call volume can indicate repeated over-invocation
 15or loop amplification by an AI agent (OWASP ASI02, Tool Misuse and Exploitation) and can lead to resource exhaustion and cost.
 16The volume counts responses that requested tools, not confirmed tool executions.
 17"""
 18false_positives = [
 19    """
 20    A legitimate spike in agent usage, such as a batch job, a load test, a launch, or a retry storm, can produce a high volume of tool-requesting responses. Confirm with the agent owner.
 21    """,
 22    """
 23    A newly onboarded caller has little history, so early bursts can look unusual until the model has learned its normal range.
 24    """,
 25]
 26from = "now-60m"
 27interval = "15m"
 28license = "Elastic License v2"
 29machine_learning_job_id = "security_ai_bedrock_asi02_high_tool_volume"
 30name = "AWS Bedrock High Tool-Request Call Volume"
 31note = """
 32## Triage and Analysis
 33
 34### Investigating AWS Bedrock High Tool-Request Call Volume
 35
 36This alert means that the number of assistant responses that requested tools in a 15-minute bucket was unusually high for the caller. The ML job uses `high_non_zero_count` over responses with at least one tool request, partitioned by `user.id`.
 37
 38### Limitations
 39
 40- The anomaly threshold is an ML record score from 0 to 100, not a tool-request count. It is set to 1 to keep recall as high as possible, because alerts were validated on a small synthetic workload from a single caller.
 41- Baselines are per caller (`user.id`). For AWS ARNs, the account ID is part of the identifier. For an assumed role, user.id ends with a session name that can change with every session or invocation (AgentCore does), so each distinct session name gets its own baseline and starts with no history. IAM users are not affected. A stable user.name (the role name) is planned for a later aws_bedrock release (2.4.0). A job that partitioned by it would give all sessions of one role a shared baseline, and roles with the same name in different accounts would share one too. Runtimes or agents that share an IAM user share one baseline. Bedrock invocation events carry no runtime ARN, so per-agent detection is not possible with this telemetry.
 42- The values are tool requests generated by the model, not confirmed tool executions. An alert does not establish malicious intent or an authorization violation.
 43- Machine learning learns repeated anomalies, so scores fade when the same behavior recurs. Persistent known-bad cases need a deterministic rule.
 44- Misuse of a familiar tool with harmful arguments at normal volume and batch size can evade this detection.
 45
 46### Possible investigation steps
 47
 48- Open the anomaly in Anomaly Explorer for job `security_ai_bedrock_asi02_high_tool_volume` and note the actual versus typical count and the `user.id` partition.
 49- Identify the caller from `user.id` and `cloud.account.id` in `logs-aws_bedrock.invocation-*` for the bucket time range.
 50- List the responses with `gen_ai.output.messages.content.toolUse.toolUseId` in that range, and look for repeating tool names (`gen_ai.output.messages.content.toolUse.name`) or identical requests that suggest a loop. Use `aws_bedrock.invocation.request_id` to pivot to the full record.
 51- Check for duplicate invocation records and for client retries or throttling errors around the same time.
 52- Review the input messages and the `security_ai` results on the same documents for signs of prompt injection or looping instructions.
 53- Check Bedrock usage, token consumption, and tool or API logs for cost or downstream impact.
 54
 55### False positive analysis
 56
 57- Scheduled batch jobs, load tests, and product launches produce legitimate bursts. Document them and, if routine, raise the rule threshold or add a scoped exception for the caller.
 58- Client retry behavior after errors can multiply requests. Fix the retry policy if this is the cause.
 59
 60### Response and remediation
 61
 62- If the burst is unexpected, throttle or temporarily disable the agent or its execution role, and stop any runaway loop.
 63- Add rate limits and maximum-iteration limits in the agent framework and the tools it calls.
 64- Review Bedrock cost and quota usage, and the downstream systems that received the requests.
 65- Escalate to the owner of the agent and the AI security team if prompt injection is suspected.
 66"""
 67references = [
 68    "https://genai.owasp.org/",
 69    "https://docs.elastic.co/en/integrations/aws_bedrock",
 70]
 71risk_score = 47
 72rule_id = "f760e048-c3f3-44b2-a87d-c3f2f73712b1"
 73setup = """
 74## Setup
 75
 76This rule requires the Security for AI integration assets, the Amazon Bedrock integration, and AWS Bedrock model invocation logs.
 77
 78### Prerequisite Requirements
 79- Install the Amazon Bedrock integration and collect the `invocation` data stream (`logs-aws_bedrock.invocation-*`). The `runtime` and `guardrails` data streams are not used.
 80- Enable AWS Bedrock model invocation logging, delivered to S3 or CloudWatch Logs, with credentials for the Elastic Agent that can read that destination.
 81- Confirm the tool-use fields are indexed: `gen_ai.output.messages.content.toolUse.toolUseId`, `gen_ai.output.messages.content.toolUse.name`, `gen_ai.output.messages.role`, `gen_ai.response.finish_reasons`, `user.id`, `aws_bedrock.invocation.request_id`, and `cloud.account.id`. Only successful `Converse` and `ConverseStream` invocations are analyzed.
 82
 83### Anomaly Detection Setup
 84- Install the [Security for AI integration](https://www.elastic.co/docs/reference/integrations/security_ai), then install its Kibana assets. This loads the `security_ai-ml` machine learning module.
 85- Create the `security_ai_bedrock_asi02_high_tool_volume` anomaly detection job from that module, or enable this rule so that the job is started for you. The job and its datafeed read the index pattern you select when you create the job (`logs-aws_bedrock.invocation-*`) directly. The datafeed derives the tool-request metrics at search time and reads `user.id` as indexed. No transform or extra index is required.
 86- Anomaly detection learns each caller's normal behavior from its own telemetry, so the job needs time to learn before its results are reliable.
 87- For more details, refer to the [anomaly detection documentation](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
 88"""
 89severity = "medium"
 90tags = [
 91    "Domain: GenAI",
 92    "Data Source: AWS Bedrock",
 93    "Platform: AWS",
 94    "Service: AWS Bedrock",
 95    "Use Case: Security for AI",
 96    "Rule Type: Machine Learning",
 97    "Rule Type: ML",
 98    "Resources: Investigation Guide",
 99    "Tactic: Execution",
100    "Tactic: Impact",
101    "Mitre Atlas: AML.T0053",
102    "Mitre Atlas: AML.T0034",
103]
104type = "machine_learning"
105
106[[rule.threat_mappings]]
107framework = "MITRE ATLAS"
108version = "2026.08"
109
110[[rule.threat_mappings.threat]]
111framework = "MITRE ATLAS"
112
113[[rule.threat_mappings.threat.technique]]
114id = "AML.T0053"
115name = "AI Agent Tool Invocation"
116reference = "https://atlas.mitre.org/techniques/AML.T0053/"
117
118[rule.threat_mappings.threat.tactic]
119id = "AML.TA0005"
120name = "Execution"
121reference = "https://atlas.mitre.org/tactics/AML.TA0005/"
122
123[[rule.threat_mappings.threat]]
124framework = "MITRE ATLAS"
125
126[[rule.threat_mappings.threat.technique]]
127id = "AML.T0034"
128name = "Cost Harvesting"
129reference = "https://atlas.mitre.org/techniques/AML.T0034/"
130
131[rule.threat_mappings.threat.tactic]
132id = "AML.TA0011"
133name = "Impact"
134reference = "https://atlas.mitre.org/tactics/AML.TA0011/"

Triage and Analysis

Investigating AWS Bedrock High Tool-Request Call Volume

This alert means that the number of assistant responses that requested tools in a 15-minute bucket was unusually high for the caller. The ML job uses high_non_zero_count over responses with at least one tool request, partitioned by user.id.

Limitations

  • The anomaly threshold is an ML record score from 0 to 100, not a tool-request count. It is set to 1 to keep recall as high as possible, because alerts were validated on a small synthetic workload from a single caller.
  • Baselines are per caller (user.id). For AWS ARNs, the account ID is part of the identifier. For an assumed role, user.id ends with a session name that can change with every session or invocation (AgentCore does), so each distinct session name gets its own baseline and starts with no history. IAM users are not affected. A stable user.name (the role name) is planned for a later aws_bedrock release (2.4.0). A job that partitioned by it would give all sessions of one role a shared baseline, and roles with the same name in different accounts would share one too. Runtimes or agents that share an IAM user share one baseline. Bedrock invocation events carry no runtime ARN, so per-agent detection is not possible with this telemetry.
  • The values are tool requests generated by the model, not confirmed tool executions. An alert does not establish malicious intent or an authorization violation.
  • Machine learning learns repeated anomalies, so scores fade when the same behavior recurs. Persistent known-bad cases need a deterministic rule.
  • Misuse of a familiar tool with harmful arguments at normal volume and batch size can evade this detection.

Possible investigation steps

  • Open the anomaly in Anomaly Explorer for job security_ai_bedrock_asi02_high_tool_volume and note the actual versus typical count and the user.id partition.
  • Identify the caller from user.id and cloud.account.id in logs-aws_bedrock.invocation-* for the bucket time range.
  • List the responses with gen_ai.output.messages.content.toolUse.toolUseId in that range, and look for repeating tool names (gen_ai.output.messages.content.toolUse.name) or identical requests that suggest a loop. Use aws_bedrock.invocation.request_id to pivot to the full record.
  • Check for duplicate invocation records and for client retries or throttling errors around the same time.
  • Review the input messages and the security_ai results on the same documents for signs of prompt injection or looping instructions.
  • Check Bedrock usage, token consumption, and tool or API logs for cost or downstream impact.

False positive analysis

  • Scheduled batch jobs, load tests, and product launches produce legitimate bursts. Document them and, if routine, raise the rule threshold or add a scoped exception for the caller.
  • Client retry behavior after errors can multiply requests. Fix the retry policy if this is the cause.

Response and remediation

  • If the burst is unexpected, throttle or temporarily disable the agent or its execution role, and stop any runaway loop.
  • Add rate limits and maximum-iteration limits in the agent framework and the tools it calls.
  • Review Bedrock cost and quota usage, and the downstream systems that received the requests.
  • Escalate to the owner of the agent and the AI security team if prompt injection is suspected.

References

Related rules

to-top