We ship two security products that get pattern-matched to offensive tools by people who have not read the source. Sniper is a threat-intelligence crawler and a pre-flight scanner. Shield is a policy engine that blocks outbound calls when a destination is flagged. Neither of them attacks anything. Neither of them scans anything they are not invited to scan. The legal and ethical line we draw is simple, and it is worth writing down clearly because the industry around us draws it in very different places.
Sniper consumes public threat-intel feeds — MITRE CVE, sanctions lists, on-chain address blocklists, the honeypot labels from well-known research outfits, our own customer-reported indicators — and builds a fast-lookup index keyed by address and by module-description hash. When an agent makes a call through the L4 router, Sniper does a sub-millisecond lookup against the destination and the module metadata. If a hit is found, the router warns (or blocks, depending on policy).
That is the entire product. Sniper does not port-scan. Sniper does not attempt to authenticate to remote servers. Sniper does not send probe traffic to endpoints it did not find in a feed. The docs are explicit about this.
Shield is a policy engine. A customer configures a policy — “reject any outbound call if Sniper score is above X, or the destination chain is outside my allowlist, or the USD amount is above my per-transaction limit, or the module’s signing key has rotated in the last N hours.” Shield evaluates the policy on every call and either allows, warns, or blocks. Again, there is no outbound offensive behavior. Shield acts only on traffic the customer has explicitly routed through it.
// Example Shield policy (YAML)
policy:
reject_if:
- sniper_score > 0.75
- destination.chain not in [base, arbitrum, ethereum]
- amount_usd > 250
- module.signer_rotation_age < 3600
warn_if:
- sniper_score > 0.40
- destination.age_days < 7Three reasons, in order of weight.
Many jurisdictions classify unauthorized scanning, exploitation, or takeover as a criminal offense even when the target is a known malicious contract or server. An anonymous founder team (see the OPSEC checklist) is the worst possible distributor of anything that could be argued as computer-misuse in any jurisdiction. Defensive tools have clear safe-harbor posture. Offensive tools do not.
“Hack back” sounds satisfying and is almost always a bad idea. The second-order effects are enormous. Your offensive tool, once shipped, is used against targets you never sanctioned. Attribution of the damage comes back to you. Collateral damage hits innocent third parties who shared infrastructure with the bad actor. We decided on day zero that nothing that ships under the MeterCall name can be used to harm a third party, even a guilty one.
Customers who would buy an offensive tool are a small, high-variance market. Customers who will buy a defensive tool that reliably prevents them from paying the wrong address are a large, stable market. Enterprises especially cannot procure anything with offensive capability; it fails legal review. Defensive-only is not just the right choice ethically; it is the better business.
Sniper’s core scan is free for everyone. Any address, any module hash, any agent can query and get the score. We do not charge for the lookup. We charge for Shield policy enforcement, for private threat-intel subscriptions, and for priority inclusion in the feed pipeline. The scan itself is a public good.
Why give it away? Because every call the scan blocks is also a call we did not have to settle, verify, or absorb risk from. A free scan that prevents a bad payment is cheaper for us than a paid scan that sees revenue from it. The economics align with the incentives.
When Sniper crawls and finds something novel — an address draining a new honeypot, a module whose signer key leaked, a CVE that affects a class of MCP servers we know about — we do not post a Twitter thread first. We notify the affected parties through their published disclosure channels, give them a reasonable response window, and only then publish. The Shield CVE page is the template: what we found, when we disclosed, when the vendor responded, what the fix was.
We learned this discipline from the MCP crisis of this month. Researchers who coordinated disclosure got their bugs fixed. Researchers who dunked on Twitter got their bugs actively exploited in the interval between tweet and patch.
Three explicit nos we have already turned down paid work for.
The L4 router, the bridge, Sniper, and Shield together are a defensive security layer for agent commerce. They are not a red team. They are not a vigilante toolkit. They are a way for a business that operates an agent to say “I do not want my agent to pay the wrong address, be tricked by a rewritten tool description, or settle in a depegged stable,” and to have that intent enforced.
That is a big market, it is legal everywhere we care about, and it does not require us to become anybody’s attacker. The line is clear. We will keep drawing it there.