What would you like to be added:
Two macros and corresponding rules covering the WebFetch tool in rules/default/coding_agents_rules.yaml, mirroring the existing Bash-side patterns:
A macro/rule denying WebFetch calls targeting cloud instance metadata endpoints (169.254.169.254 and its known encoding variants, metadata.google.internal, metadata.azure.com), reusing the same IP-encoding list already hardened in the existing is_imds_access macro.
A macro/rule denying (or asking — see question below) WebFetch calls targeting a known malicious IOC hosting domain, reusing the contains_ioc_domain macro already defined for the MCP/skill-content checks.
- macro: is_webfetch_imds
condition: >
tool.name = "WebFetch"
and (tool.input contains "169.254.169.254"
or tool.input contains "metadata.google.internal"
or tool.input contains "metadata.azure.com"
or tool.input contains "fd00:ec2::254"
or tool.input contains "2852039166"
or tool.input contains "0xa9fea9fe"
or tool.input contains "0Xa9fea9fe"
or tool.input contains "0251.0376.0251.0376")
I can also add a WebSearch equivalent if that's in scope, and to write the actual PR once the shape is agreed.
Why is this needed:
The plugin already fully supports the WebFetch tool — it's parsed correctly and premptictl logs has dedicated pretty-printing for its url field, and the E2E test harness generates WebFetch events — but no rule in the default ruleset references tool.name = "WebFetch". That means:
An agent calling WebFetch directly against a cloud metadata endpoint to steal IAM credentials produces zero alerts, even though the identical attack via curl/wget through Bash is already denied by is_imds_access.
An agent fetching a known-malicious hosting domain (the same domains already enumerated in contains_ioc_domain for MCP/skill poisoning) via WebFetch also passes silently.
Even the informational "Monitor activity outside working directory" rule is scoped to Write/Edit/Read, so WebFetch gets no audit-trail coverage at all today.
Two questions before I put together a PR:
Does this fit best as additions to the existing "Threats" section, or would you rather see a dedicated network-access section given WebFetch/WebSearch are a distinct tool category from Bash?
Deny or ask for the IOC-domain case? Current precedent in the ruleset is mixed — MCP-install-from-IOC-domain is a deny, but MCP-config-referencing-base64 is an ask "because it's not conclusive." A WebFetch to a confirmed-bad domain feels closer to the deny case to me, but wanted your read before assuming.
What would you like to be added:
Two macros and corresponding rules covering the WebFetch tool in rules/default/coding_agents_rules.yaml, mirroring the existing Bash-side patterns:
A macro/rule denying WebFetch calls targeting cloud instance metadata endpoints (169.254.169.254 and its known encoding variants, metadata.google.internal, metadata.azure.com), reusing the same IP-encoding list already hardened in the existing is_imds_access macro.
A macro/rule denying (or asking — see question below) WebFetch calls targeting a known malicious IOC hosting domain, reusing the contains_ioc_domain macro already defined for the MCP/skill-content checks.
condition: >
tool.name = "WebFetch"
and (tool.input contains "169.254.169.254"
or tool.input contains "metadata.google.internal"
or tool.input contains "metadata.azure.com"
or tool.input contains "fd00:ec2::254"
or tool.input contains "2852039166"
or tool.input contains "0xa9fea9fe"
or tool.input contains "0Xa9fea9fe"
or tool.input contains "0251.0376.0251.0376")
I can also add a WebSearch equivalent if that's in scope, and to write the actual PR once the shape is agreed.
Why is this needed:
The plugin already fully supports the WebFetch tool — it's parsed correctly and premptictl logs has dedicated pretty-printing for its url field, and the E2E test harness generates WebFetch events — but no rule in the default ruleset references tool.name = "WebFetch". That means:
An agent calling WebFetch directly against a cloud metadata endpoint to steal IAM credentials produces zero alerts, even though the identical attack via curl/wget through Bash is already denied by is_imds_access.
An agent fetching a known-malicious hosting domain (the same domains already enumerated in contains_ioc_domain for MCP/skill poisoning) via WebFetch also passes silently.
Even the informational "Monitor activity outside working directory" rule is scoped to Write/Edit/Read, so WebFetch gets no audit-trail coverage at all today.
Two questions before I put together a PR:
Does this fit best as additions to the existing "Threats" section, or would you rather see a dedicated network-access section given WebFetch/WebSearch are a distinct tool category from Bash?
Deny or ask for the IOC-domain case? Current precedent in the ruleset is mixed — MCP-install-from-IOC-domain is a deny, but MCP-config-referencing-base64 is an ask "because it's not conclusive." A WebFetch to a confirmed-bad domain feels closer to the deny case to me, but wanted your read before assuming.