Block the fetch that reaches your metadata endpoint.
A server-side request to a user-supplied URL can pivot to 169.254.169.254 and steal cloud credentials. AI writes this whenever a feature "fetches a URL the user gives." SlopGrade blocks it in CI before merge.
A user-controlled URL, fetched server-side.
Nothing validates the host, so an attacker points it at the cloud metadata service or an internal admin panel. Allowlisting the destination fixes it — the gate blocks the un-allowlisted fetch.
What the AI shipped
What leaves your runner
Path, line, class. On a private repo the file content stays on the runner by default; the deep scan (heisen-slop) is a paid opt-in. Audit it with --print-payload.
Detect → adapt → verify. By default, nothing else leaves.
In your runner, on the diff
The open-source client walks the pull request and flags the pattern locally — intra-function dataflow. By default, no code leaves the machine.
Server verdict + gate
The structural fingerprint is classified server-side. A hard hit blocks the check on a paid private repo; public repos are gated free; the paywall fails open.
Posted inline, re-checked on push
The finding is posted on its exact line. For the few classes with a safe deterministic rewrite (TLS verification off, debug on, yaml.load…), a fix is generated AND verified in your runner; otherwise you fix it and the next push re-checks.
What if the URL is partly validated?
A destination allowlist (scheme + host) is recognized as safe. A bare protocol check (startsWith https) is not — it still allows internal hosts. The gate is calibrated to that distinction.
Which languages?
JavaScript/TypeScript and Python for the full class; Go and .NET cover the core fetch/HTTP-client patterns.