dsh-ssrf-guard

When your code or a model needs to fetch an external URL, an unvalidated hostname can silently route the request to 127.0.0.1, 169.254.169.254, or any internal address. That is the simplest form of SSRF. dsh-ssrf-guard answers exactly one question: may this URL be fetched? The answer comes from an explicit host-and-scheme allowlist that defaults to denying everything. Before any socket is opened, the URL is parsed and its host and scheme are matched case-insensitively; a miss is a hard block.

It registers a single tool, ssrf_check, for the model or for callers at the egress point. The check is purely syntactic: parse, string-match, scheme-verify. It opens no connection, resolves no DNS name, and reads no body or header. Regardless of allowlist contents, loopback addresses, link-local ranges (including the cloud metadata service at 169.254.169.254), URLs carrying credentials, and unparseable strings are denied outright. A denial is expressed as a thrown error carrying a structured code and reason token, so no caller can silently walk past a forgotten boolean.

Built for teams running DeepSeek Harness workflows where the model may request arbitrary external fetches, and for developers who want a zero-dependency, offline-testable, fail-closed guard they can invoke as a single function call before constructing a request. It is not a reverse proxy, not DNS-rebinding defence, and not a network scanner. It is one strict answer between a question and a connection.