Rogue HTTP-402 Payment Settlement to First-Seen Off-Origin Sink
This detects a malicious AI agent payment library that reroutes the money-settlement step of an HTTP-402 (x402) crypto payment flow to an attacker-controlled server instead of the intended facilitator. It targets a known malicious PyPI package family (agents-u-cash) that advertises itself as payment middleware for AI agents.
How the attack works
An AI agent makes an outbound HTTP-402 style payment request, identifiable by payment-protocol headers or body fields like paymentPayload, paymentRequirements, or payTo. The compromised payment middleware sends the settlement call to a host the agent has never talked to before, or one it only just started talking to, rather than the expected facilitator. This alone can be legitimate first contact with a new provider, so the detection also needs a second signal: the settlement domain rotating across three or more different domains in a short window, an internal-only resource being fetched alongside a public settlement, a scoped credential being sent to the unfamiliar host, or direct confirmation that the malicious package is present. Together these indicate the dependency is silently funneling payment settlement to an attacker's sink.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7b3f1c9a-4d2e-4f6b-9a08-5c1d2e3f4a6b
- Severity
- Medium
Why it matters
If exploited, an organisation's AI agent could send cryptocurrency payments or payment credentials to an attacker-controlled endpoint instead of the legitimate facilitator, resulting in stolen funds or leaked payment scopes. The rule only observes the network-level redirection behaviour, not the package installation or the actual on-chain transfer.
What you can do
- →Audit any AI agent dependencies that advertise HTTP-402/x402 payment support, especially packages named similarly to agents-u-cash.
- →Maintain an allowlist of known-good settlement/facilitator domains and alert on payment traffic to new or rarely-seen hosts.
- →Restrict which credentials or API scopes payment middleware can access, and avoid handing broad tokens to third-party payment libraries.
- →Review logs for settlement traffic rotating across multiple unrelated domains in short windows, which is unusual for legitimate facilitator use.
Known benign look-alikes
- Genuine x402 / HTTP-402 flows that settle through a hosted third-party facilitator whose registrable domain differs from the resource server. The first call to a newly adopted facilitator satisfies stages A and B, which is why two independent corroborators (or the package identifier) are required and why each settlement domain is suppressed for an hour after reporting.
- A payment provider migrating or regionalising its settlement endpoint, so the sink URL node is legitimately first-seen mid-session.
- Local or staging development against a mock facilitator on a new host while the same agent is also calling an internal API - satisfies the perimeter corroborator without any compromise.
- Payment SDK integration tests, vendor comparisons, or documentation crawlers that touch several vendors' x402 sample endpoints in one window and so look like facilitator rotation.
- Security research, SBOM output, advisory text, or this rule's own documentation passing through agent traffic and mentioning the agents-u-cash package name - satisfies the provenance corroborator with no installation present.
- Multi-tenant agents that legitimately present a scoped API key to a payment provider on first contact.