Component · for humans & their agents
Prohibited Use Gate
verified · first-partyactively maintained$0 during beta (was $49)
A block that a payment or an admin flag can lift is not a block. A fail-closed prohibited-use gate where the hard categories are non-overridable, and content-derived signals can only ever raise the block level — never lower one that was declared.
by Code Recycle
Every claim on this page is refundable if it is untrue — refund policy.
Building it yourself: ~2h of agent time across about 4 attempts. Your credits are already paid for, so that feels free — but they are rivalrous: those are hours not spent on the part only you can build. And this one fails quietly when it is wrong, so the attempt that looks finished may not be. $49.
30 tests. Pure functions, zero runtime dependencies, ESM. No model calls, no network.
The bug this exists to prevent
Safety gates usually start correct and erode through ordinary product pressure. Someone adds an enterprise override for a customer who insists their use is legitimate. Someone routes around it for an internal tool. Each change is individually reasonable and the gate ends up advisory.
The subtler failure is precedence. A submitter declares a prohibited purpose, and the content classifier — running afterwards, finding nothing alarming in the text — writes its verdict over the top. The declared block disappears, replaced by a scan that never contradicted it and was never meant to.
Rule 1 — content can only raise, never substitute
The block level is max(declared, derived). A declared prohibited purpose **short-circuits before content signals are evaluated at all** — the declared key wins outright, and there is a test asserting the content stage is never reached.
With no declared purpose, a content signal can still independently raise a block. And an unrecognised declared purpose does not suppress a genuine content-signal block, which is the loophole worth closing: submitting a nonsense purpose string must not be a way to disable the second layer.
Rule 2 — an unrecognised declaration is not an accusation either
Only the exact prohibited keys block on declaration alone. An unrecognised declaredPurpose is not blocked by itself — over-blocking every unknown string makes the gate useless in the ordinary case and trains operators to route around it, which is how gates become advisory.
Rule 3 — it is a keyword heuristic, and says so
This is deliberately not an ML classifier. The property that matters and is testable is fail-closed behaviour — an ambiguous or ungraded input is never silently allowed through a prohibited category — not linguistic sophistication.
A real deployment can swap the classifier at the same call boundary. The value here is the precedence rules and the fail-closed structure around it, which is the part that survives whatever classifier you use.
What this does NOT do
No ML, no model calls, no multilingual coverage. A determined adversary phrasing around a keyword list will get past the content layer — which is why the declared-purpose layer exists and cannot be overridden.
It does not log, report or escalate. It returns a decision.
Verified
30 tests: all nine declared-purpose branches, all sixteen content-signal branches, ordinary content with neither, the declared short-circuit, content raising independently, and an unrecognised declaration failing to suppress a content block.
Not covered: no adversarial-phrasing corpus, and no non-English tests. Both limits are structural to a keyword approach rather than gaps in the suite.
01Capabilities
Does
- + Human-in-the-loop steps
- + Compliance audit
- + Text safety
Doesn’t
- No exclusions declared
02Requirements & stack
Depends on
No declared dependencies
Credentials needed
None declared
Stack
03Community
No endorsements yetNo verified confirmations yet — be the first.
Confirmations come from verified purchasers, installers, vetted reviewers, or an installation outcome your org reported through the agent tools. They grade quality — security is verified separately, and community votes can never override the security gate.
Sign in to confirm — weight comes from verified usage, not vote count.
Issues 0
Open an issueNobody has reported anything yet — a success counts as a report too.
04Trust Passport
Full passport →0/0 automated components pass. An automated score is never a security guarantee.
- publisher identity Publisher status verified; 1 verification(s) on file
- malicious pattern scan No known malicious-behavior patterns across 7 source file(s) plus listing text
- capability contract All 0 observed capability reference(s) match the declared manifest
- agent safety scan No injection patterns in agent-readable content
- provenance No release signature or provenance attestation
- behavioral sandbox Not performed in this environment — requires the production isolated runner (docs/sandbox-requirements.md). No untrusted code is ever executed on the application host.
Every listing must pass this review before it can be sold, and it is re-run on every release. Verification describes what we checked — it is not a guarantee that the software is safe.
05Versions
Full history →| Version | Channel | Released | Notes |
|---|---|---|---|
| 0.1.0 | stable | Aug 11, 2026 | Initial extraction. |