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_volumeand note the actual versus typical count and theuser.idpartition. - Identify the caller from
user.idandcloud.account.idinlogs-aws_bedrock.invocation-*for the bucket time range. - List the responses with
gen_ai.output.messages.content.toolUse.toolUseIdin that range, and look for repeating tool names (gen_ai.output.messages.content.toolUse.name) or identical requests that suggest a loop. Useaws_bedrock.invocation.request_idto 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_airesults 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
- AWS Bedrock Unusual Tool Selection
- AWS Bedrock Unusually Large Tool-Request Batch
- High Confidence Prompt Injection in a GenAI User Message
- AWS Bedrock High Risk Filesystem or Execution Tool Invocation
- AWS Bedrock Provisioned Model Throughput Tampering