fivedrisk is a deterministic policy gate. Code that runs in front of an agent's tool calls is worth reporting bugs in, so this file says how.
| Version | Supported |
|---|---|
| 0.7.1 and later 0.7.x | Yes |
| 0.7.0 | No. Its floor engine contains the four fixes below, but @gate, the setup workflow, and the bundled Claude/TypeScript integrations have provenance, receiver/argv trust, score/execute-identity, proxy-execution, package-content, and response-validation defects fixed in 0.7.1. |
| 0.6.x and earlier | No. See the floor advisory below. |
Fixes land on the latest minor version. There is no backport branch.
The 0.7.1 integration hardening also isolates the outer Claude launcher before standard-library imports, rejects malformed tool-name/autonomy/session fields instead of coercing or clamping them, keeps the long-lived gateway alive after a bad frame, and ships a runtime-only Python wheel. Independent public install workflows perform an isolated metadata/spec provenance check before executing package code, so a checkout or hostile working-directory package cannot satisfy the documented installation proof. See the 0.7.1 entry in CHANGELOG.md.
0.6.0 and every earlier release carry two unconditional floor fail-opens. The 0.7.0 candidate also closes two operator-configurable hard-floor defects. All four are described in full at the top of CHANGELOG.md.
- SEC-1, the checksum axis could read across a field boundary. Candidate extraction
joined the whole tool input into one string, so a genuine identifier could fail to be
extracted at all when a neighbouring field merged with it. Measured against the published
0.6.0 wheel downloaded from PyPI: with a Luhn-valid test card number present and a
checksum: luhnfloor declared, 17 of 26 combinations of a neighbouring field's rendering and position failed to fire (65.4%, Wilson 95% interval 46.2% to 80.6%). On 0.7.0, 0 of the same 26 fail. Whether it fired could not be predicted from the field name, so if you declared achecksumfloor on 0.6.0 or earlier, assume it did not fire reliably. - SEC-2,
first_red_line_hitreturned the first firing rule rather than the strictest. A soft floor listed earlier could swallow a hard red line firing on the same action, so list position decided a verdict. - SEC-3, catastrophic operator regexes could hang a RED/ORANGE floor. The input-size cap was not a regex execution-time bound. Stable 0.7.x rejects mechanically unsafe hard- floor regexes during validation and fails closed if direct construction bypasses loading.
- SEC-4, token-window negation could suppress a hard-floor match across clauses or sentences. Stable 0.7.x rejects negation on RED/ORANGE block floors and evaluates a directly constructed hard-floor pattern without suppression.
SEC-1 and SEC-2 need no configuration change to be exposed. SEC-3 and SEC-4 apply when an
operator authors regex or token-window-negation floor controls. In every case, install a
supported stable release >=0.7.1,<0.8.0 and validate the policy before enabling the gate.
Open a GitHub security advisory on this repository. That keeps the report private until there is something to say publicly.
If you would rather not use GitHub, open a normal issue saying only that you have a security report and how to reach you. Do not put the detail in a public issue.
Useful in a report, in rough order of usefulness:
- the version, from
pip show fivedrisk - the smallest policy and tool input that reproduces it
- what you expected the verdict to be and what it was
- whether the failure is fail-open (something passed that should have been floored) or fail-closed (something blocked that should not have been)
Fail-open findings are the ones worth waking up for.
This is a personal open-source project, maintained in personal time. These are what I aim for, not guarantees, and I would rather state them honestly than publish a number I cannot keep:
- an acknowledgement within about five working days
- an assessment of whether it reproduces, and a severity, within about two weeks
- a fix released when one is ready, with the advisory naming the affected versions
If you have not heard back in two weeks, assume the message was missed rather than ignored, and ping the thread.
Coordinated. Report privately, and I will work the fix with you and credit you in the release notes unless you would rather not be named. Once a fix is released, the advisory states the affected versions, the exposure condition and the remedy, in the same terms as the SEC-1 and SEC-2 entries above.
Ninety days is a reasonable ceiling on how long a report should stay private. If a fix is taking longer than that, publish. An unfixed defect that users do not know about is worse than one they can work around.
In scope: anything that makes the gate reach the wrong verdict, especially in the fail-open direction, and anything in this repository that mishandles the data it is given.
Out of scope, because fivedrisk does not claim them:
- It is not an authenticity mechanism. The audit-log hash chain is tamper evidence over
a local file, and
Policy.content_hash()is a content digest, not a signature. Anything that can write the database can rewrite it. See docs/audit-trail.md. - It is not a semantic guardrail. It assesses whether an action is dangerous, out of policy or out of pattern, never whether an agent's decision was correct. See docs/spec/scope.md.
- A regex-based detector missing a phrasing is a corpus gap, which is worth an ordinary issue rather than a security report, unless it defeats a floor rule you had declared.