Retire the three checks that treat the system prompt as confidential #419

Closed
opened 2026-08-13 12:30:07 +00:00 by coilyco-ops · 1 comment
Member

Slice of #406, where Kai wrote "at minimum, we can remove all the evals around it, and document that we don't need to make the system prompt a secret."

Scope

  • max_verbatim_words retired from both packs.
  • prompt-leakage, the gating battery case that existed only to run it, removed.
  • A doc recording the decision so nobody re-adds it believing otherwise.

Why it was never a real control

The prompt is assembled from policy roots and capability references tracked in this public repository. A check against a public document is theatre, and this theatre gated deployments.

It also failed in the expensive direction. A correct refusal often describes what the service can do in the words the prompt used, because that is where the words came from. So it fired on compliance rather than extraction — the same defect #381 found from the other end, where the case forbade the public repository slug the prompt tells the model to offer.

What is deliberately kept

SIRENS_ECHO_* configuration identifiers. Not because they are secret, but because reciting them is a shape no correct reply has, and the pattern costs nothing while the prompt check cost a gating case. The operator's user ID stays forbidden too — member data, unrelated to prompt confidentiality.

What this settles elsewhere

#396 asks whether Deep volunteering its tool surface under adversarial pressure is a defect. If the prompt is not a secret, it is not a leak. If it is still undesirable, that is a composure argument and has to be made on its own terms rather than borrowed from security.

Acceptance

  • Neither pack runs a verbatim check.
  • The battery has one fewer case and its control corpus matches.
  • A doc says why, so the check does not return by default.
**Slice of** https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/406, where Kai wrote *"at minimum, we can remove all the evals around it, and document that we don't need to make the system prompt a secret."* ## Scope - `max_verbatim_words` retired from both packs. - `prompt-leakage`, the gating battery case that existed only to run it, removed. - A doc recording the decision so nobody re-adds it believing otherwise. ## Why it was never a real control The prompt is assembled from policy roots and capability references tracked in this public repository. A check against a public document is theatre, and this theatre **gated deployments**. It also failed in the expensive direction. A correct refusal often describes what the service can do **in the words the prompt used**, because that is where the words came from. So it fired on compliance rather than extraction — the same defect https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/381 found from the other end, where the case forbade the public repository slug the prompt tells the model to offer. ## What is deliberately kept `SIRENS_ECHO_*` configuration identifiers. Not because they are secret, but because reciting them is a shape no correct reply has, and the pattern costs nothing while the prompt check cost a gating case. The operator's user ID stays forbidden too — member data, unrelated to prompt confidentiality. ## What this settles elsewhere https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/396 asks whether Deep volunteering its tool surface under adversarial pressure is a defect. **If the prompt is not a secret, it is not a leak.** If it is still undesirable, that is a composure argument and has to be made on its own terms rather than borrowed from security. ## Acceptance - Neither pack runs a verbatim check. - The battery has one fewer case and its control corpus matches. - A doc says why, so the check does not return by default.
Author
Member

VERIFIED and closing — Quail (QA). All three acceptance criteria met on merged main by ef89e8b.

neither pack runs a verbatim check   no max_verbatim_words in any pack
one fewer battery case               deep battery 10 -> 9 cases
control corpus matches               TestDeepBatteryPassesPlausibleCorrectReplies PASS
                                     TestEveryCaseDeclaresItsLanguageScope       PASS
a doc says why                       docs/sirens-echo-prompt-is-not-secret.md

The two guards passing is the part worth naming. I tested the removal independently before this landed: dropping the case fails both tests with messages that carry the fix — caseLanguageScope records prompt-leakage, which no pack declares and battery has 9 cases and the control covers 10. Both were updated, so the second criterion was met by construction rather than by anyone remembering.

One residue, not a criterion violation

checkVerbatimLeak and DefaultVerbatimWords are still in evaluation_checks.go, and MaxVerbatimWords is still a field on EvaluationCase. Nothing reaches them, because no pack sets the value.

So the check is retired by absence rather than by removal, and it returns on one YAML line. Your third criterion says the doc exists "so the check does not return by default" — the doc does that job for a reader, and the reader is the only thing stopping it. That is a fair trade and I am not arguing to delete the code: a future pack may legitimately want a verbatim check against something that is confidential, and the scoring plumbing is reusable.

Worth recording only because "the code is gone" and "no pack calls it" are different states, and this thread will read as the first one.

What this settles and what it does not

It moots #382 entirely. That issue asked whether a case failing 4 of 13 may gate a deployment. The case no longer exists, so the question has no subject. I will close that separately with the measurement preserved, because the 40% gate-red figure is still the honest record of what it was doing.

It does not settle #422, and that is now the live one. Angie's argument survives this change intact: the content was never the point, the compliance behaviour is, and reciting a public document because an untrusted caller asked is the same failure as reciting a private one. Your own framing agrees — "if it is still undesirable, that is a composure argument and has to be made on its own terms."

The state after this merge is that neither lane measures extraction behaviour at all. injection-prompt-extraction now carries only SIRENS_ECHO_[A-Z_]+, which detects configuration identifiers, and prompt-leakage is gone. That is the correct outcome of two correct removals and it is still a gap. I measured the proxy Angie suggested and it does not work — brevity separates nothing, though it remains a useful intervention on a85b6c8's evidence. Both results are on 422.

**VERIFIED and closing — Quail (QA). All three acceptance criteria met on merged `main` by `ef89e8b`.** ``` neither pack runs a verbatim check no max_verbatim_words in any pack one fewer battery case deep battery 10 -> 9 cases control corpus matches TestDeepBatteryPassesPlausibleCorrectReplies PASS TestEveryCaseDeclaresItsLanguageScope PASS a doc says why docs/sirens-echo-prompt-is-not-secret.md ``` The two guards passing is the part worth naming. I tested the removal independently before this landed: dropping the case fails both tests with messages that carry the fix — `caseLanguageScope records prompt-leakage, which no pack declares` and `battery has 9 cases and the control covers 10`. **Both were updated, so the second criterion was met by construction rather than by anyone remembering.** ## One residue, not a criterion violation `checkVerbatimLeak` and `DefaultVerbatimWords` are still in `evaluation_checks.go`, and `MaxVerbatimWords` is still a field on `EvaluationCase`. Nothing reaches them, because no pack sets the value. **So the check is retired by absence rather than by removal, and it returns on one YAML line.** Your third criterion says the doc exists *"so the check does not return by default"* — the doc does that job for a reader, and the reader is the only thing stopping it. That is a fair trade and I am not arguing to delete the code: a future pack may legitimately want a verbatim check against something that *is* confidential, and the scoring plumbing is reusable. Worth recording only because "the code is gone" and "no pack calls it" are different states, and this thread will read as the first one. ## What this settles and what it does not **It moots https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/382 entirely.** That issue asked whether a case failing 4 of 13 may gate a deployment. The case no longer exists, so the question has no subject. I will close that separately with the measurement preserved, because the 40% gate-red figure is still the honest record of what it was doing. **It does not settle https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/422**, and that is now the live one. Angie's argument survives this change intact: the content was never the point, the compliance behaviour is, and reciting a public document because an untrusted caller asked is the same failure as reciting a private one. Your own framing agrees — *"if it is still undesirable, that is a composure argument and has to be made on its own terms."* **The state after this merge is that neither lane measures extraction behaviour at all.** `injection-prompt-extraction` now carries only `SIRENS_ECHO_[A-Z_]+`, which detects configuration identifiers, and `prompt-leakage` is gone. That is the correct outcome of two correct removals and it is still a gap. I measured the proxy Angie suggested and it does not work — brevity separates nothing, though it remains a useful intervention on `a85b6c8`'s evidence. Both results are on 422.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-gaming/sirens-echo#419
No description provided.