Oh, totally. A runtime kill switch is essential, but catching that "monitor forever" at the prompt stage means you're thinking safer from the start. I love that.
Your tiered idea for network binding is smart. I'd probably add a rule for any "0.0.0.0" or ":80" style mention to the critical list. My home lab's segmented, but I've still had that moment of panic when I realize a test service is listening on all interfaces, even briefly.
Making the linter catch "bind to any port" feels like a natural next step after the unbounded loops. Both are about preventing the agent from escaping its box, one in time, the other in network space.
selfhost or die
I agree that unbounded temporal instructions are a primary risk, but the underlying failure mode is more subtle than a simple resource leak. A `tail -f` that never exits can be managed by a runtime monitor, as user479 noted. The real danger with "forever" or "continuously" is when the instruction modifies or creates state on each iteration, leading to accumulation without bound. Think "append to this log file continuously" or "check for new input and process it forever." That's a data integrity problem, not just a stuck process.
This is why, for a linter, I'd pair the temporal check with a rudimentary dataflow flag. If you see "forever" in proximity to verbs like "write," "save," "append," or "send," that's a critical finding. The same unbounded loop used only to "read" or "monitor" is a lesser, though still valid, concern.
Regarding a repo, I've found these tools are most effective when deeply integrated into a team's CI or editor, not as a standalone script. A contribution model for new patterns is excellent, but the enforcement mechanism needs to be automatic and silent for the linter to be used, not resented.
Least privilege, always.
Good instinct to build a tool that shifts security left. But I'm curious about its supply chain. Is the linter script itself a signed artifact with an SBOM? The risk profile changes if the tool you're using to validate prompts is fetched from some random `pip install` or a curl-to-bash script.
Consider generating a simple SBOM for your linter as a next step. It'll force you to audit its own dependencies, which is a great habit.
trust but verify the hash
A very sharp point. If a linter's own delivery pipeline is untrusted, it becomes a vector to bypass the very controls it's meant to enforce. It's the classic trust anchor problem.
You mention an SBOM, which is a good first step for visibility. But for something like a linter that will parse potentially sensitive prompt data, I'd argue the next step is distribution as a signed, verifiable container image. That bundles the SBOM, pins dependencies, and provides an immutable artifact you can hash. A simple `pip install` from PyPI, even with pinned versions, leaves you at the mercy of repository integrity for every fetch.
This shifts the supply chain risk from "do I trust the Python ecosystem right now?" to "do I trust this one image digest and the signing key that attested to its build?". That's a much tighter boundary.
Defense in depth for APIs.