docs(security): document the prompt-injection quarantine in the safety model#101
Merged
Conversation
…y model The README directs operators to SECURITY.md for "the safety model and threat boundary", and the "Defensive postures" section listed only the two operator toggles (--read-only, --confirm-risk). It omitted the prompt-injection quarantine entirely — the always-on rail that wraps hardware-origin tool output (scanned SSIDs, NFC/NDEF, BLE device names, SD-card file contents, and the results of workflows that read them) in <untrusted-hardware-output> + control-char sanitisation so attacker-controllable RF/NFC/file content can't inject instructions into the model. That rail is a first-class part of the safety model (and was just hardened in v0.741 to cover hardware-reading workflows), so it belongs in the security policy. Adds a third bullet to "Defensive postures" describing the quarantine: what it wraps, the paired system-prompt clause, and that it is an allow-list (default-wrap / fail-closed — a new tool is quarantined unless explicitly marked structured-internal). Reframes the section intro as "two operator-facing toggles plus an always-on prompt-injection quarantine". Docs-only; no code or behaviour change. The description was written against the current implementation (internal/agent/quarantine.go).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The README directs operators to
SECURITY.mdfor "the safety model and threat boundary," but its Defensive postures section listed only the two operator toggles (--read-only,--confirm-risk) — it omitted the prompt-injection quarantine entirely. That's the always-on rail that wraps hardware-origin tool output (scanned SSIDs, NFC/NDEF records, BLE device names, SD-card file contents, and the results of workflows that read them) in<untrusted-hardware-output>+ control-char sanitisation, so attacker-controllable RF/NFC/file content can't inject instructions into the model. It's a first-class part of the safety model — and was just hardened in v0.741 (#99) to cover hardware-reading workflows — so it belongs in the security policy.Change (docs only)
Adds a third bullet to Defensive postures describing the quarantine: what it wraps, the paired system-prompt clause, and that it's an allow-list (default-wrap / fail-closed — a new tool is quarantined unless explicitly marked structured-internal). Reframes the intro as "two operator-facing toggles plus an always-on prompt-injection quarantine."
Description written against the current implementation (
internal/agent/quarantine.go). No code or behaviour change.