[New Rule] AWS Bedrock AgentCore Gateway Repeated Tool Invocation Failures

[eeee2345]

Pull Request

Issue link(s):

Related to #6126

Summary - What I changed

One ES|QL seed rule for the aws_bedrock_agentcore integration, as agreed in #6126: rules/integrations/aws_bedrock_agentcore/aws_bedrock_agentcore_gateway_repeated_tool_invocation_failures.toml

What it detects: a burst of failed tool invocations against the same AgentCore Gateway target within a short window (aws.bedrock_agentcore.gateway.payload_object.isError equals the string true, bucketed into 5-minute windows, grouped by gateway, tool, and target). A concentrated run of failures against one target from one gateway is the observable signature of an attacker or compromised tool wrapper probing a tool's parameter surface for an injection point, an auth bypass, or a schema weakness, as opposed to ordinary transient failures spread across many targets and callers. It is a behavioral threshold over gateway telemetry, not a content match, so it is not bypassed by rephrasing the probe payload.

Two implementation details worth a reviewer's eye:

The gateway payload_object field is an Elasticsearch flattened field, so isError, a JSON boolean in the source payload, is indexed as the keyword string true rather than the boolean true. Comparing against the boolean silently matches nothing, which is documented inline in the query.

The failure-count threshold of five is a placeholder. The main false-positive case, documented in the false_positives list, is a target that is broken for every caller rather than one caller probing it, so this needs tuning per environment rather than trusting the fixed number.

Also included: the corresponding scoped entry in the integration manifests file, regenerated with the repo's own manifest-build tooling for this integration only. This integration had no prior rule in the repo, so its manifest entry was missing locally and the package test fails without it.

Important finding to flag for Mikaayenson, and for future contributors to this integration

In my last comment on #6126 I proposed two more behavior-focused candidates: a tool call whose arguments match a credential-exfiltration pattern, and a tool description that carries imperative instructions to the agent, i.e. tool poisoning. Before writing either as a rule I checked what fields the aws_bedrock_agentcore integration actually populates today, across all three relevant data streams in elastic slash integrations: gateway_application_logs, runtime_application_logs, and memory_application_logs.

No stream exposes a structured tool-call-arguments field. gateway_application_logs has a tool name field and a target field, but the only place invocation arguments could live is inside the flattened payload_object blob, which is not addressable as a discrete field for an arguments-pattern rule.

No stream exposes a tool-description or tool-definitions field at all.

Neither the gen_ai.tool namespace referenced in ECS RFC 0052, elastic/ecs pull request 2532, merged 2026-05-07, which does define fields like tool.call.arguments, tool.definitions, and tool.call.result, nor any equivalent custom field appears anywhere in the aws_bedrock_agentcore package's field definitions. The schema exists in ECS; as far as I can find, no shipping Elastic integration populates it yet.

I also could not find a darg package in elastic slash integrations, which I asked about in my May 29th comment without a direct answer. If it exists it is not public, so I could not check whether it is the one that populates gen_ai.tool fields.

So both candidates I floated on June 25th are currently undetectable against real data from this integration, not because the behavior is not worth watching for, but because the field does not exist yet to watch it in. Rather than ship a rule against fields I cannot verify are populated, or block on integration and ECS work I do not control, I used this PR to cover the one gateway-side behavior that is fully observable today with the fields that exist now: repeated failure against a single target. That is adjacent in spirit, a repeated or probing tool-call pattern against a specific target, even though it does not require the argument or description content. This is also the detection-logic pairing this rule is closest to in the Agent Threat Rules catalog I maintain: unauthorized-tool-call, which covers malicious or anomalous tool-call parameter patterns, and mcpwn-runaway-invocation, which covers repeated or looping tool-call abuse. Same behavioral family, applied here to the fields this integration actually emits.

Flagging this here because the team may not be tracking that the gen_ai.tool field gap is still open on the integration side even though the ECS PR merged two months ago. Worth knowing before scoping any follow-on tool-call-content rule for this integration, or for darg if and when it becomes public. Happy to pick this back up the moment there is a populated field to key off of.

How To Test

Ran the repository's full pytest suite against the same virtual environment the Makefile deps target builds. Result: 255 passed, 19 skipped, 2 subtests passed. The rule also loads and passes schema and lint validation as part of that same run, since test_packages, test_all_rules, and test_schemas are all in that suite.

Checklist

Added a label for the type of pr: Rule: New
Secret and sensitive material has been managed correctly
Automated testing was updated or added to match the most common scenarios: manifest entry regenerated so the package test covers this integration
Documentation and comments were added for features that require explanation: inline query comments plus an investigation guide in the rule's note field

Contributor checklist

Have you signed the contributor license agreement? Yes
Have you followed the contributor guidelines? Yes