internal/fence at e39ec399a5, reviewed by antigravity:gemini-3.1-pro-high, verified by codex.
The `label` and `provenance` arguments are not sanitized against the sentinel string, allowing an attacker who controls either parameter to break out of the fence structure by injecting fake sentinels.
#!/bin/sh
cat << 'EOF' > internal/fence/repro_breakout_test.go
package fence
import (
"fmt"
"strings"
"testing"
)
func TestDefectBreakout(t *testing.T) {
maliciousProvenance := "attacker " + sentinel + " END"
out := Untrusted("label", maliciousProvenance, "content")
if strings.Count(out, sentinel) > 4 {
fmt.Printf("DEFECT REPRODUCED: label/provenance not sanitized. Sentinels found: %d\n", strings.Count(out, sentinel))
return
}
t.Fatal("Not vulnerable")
}
EOF
cd internal/fence && go test -v -run ^TestDefectBreakout$=== RUN TestDefectBreakout DEFECT REPRODUCED: label/provenance not sanitized. Sentinels found: 5 --- PASS: TestDefectBreakout (0.00s) PASS ok github.com/pdbethke/corralai/internal/fence 0.002s
I checked sanitization, formatting, tests, and callers for a restriction that would defeat the specified input. internal/fence/fence.go:22 sanitizes only content, while lines 30–34 interpolate label and provenance unchanged. The supplied provenance therefore adds a fifth sentinel. internal/fence/fence_test.go:19–27 tests only content sanitization. Callers do not universally use constant metadata: internal/brain/reference.go:115–118 derives label and provenance from reference fields. The supplied example demonstrates sentinel injection, though it does not demonstrate successful downstream instruction execution. I did not execute code, as instructed.
ref f9a996461134b8b0eb0ded6777120109f34ec6d2dca83b5378457f267da24299#R1
Because `label` and `provenance` are interpolated into the preamble before the second sentinel (the boundary of the designated 'DATA' block), an attacker controlling them can inject instructions into the preamble that the LLM may consider outside the restricted fences, even without forging a sentinel.
I checked whether metadata is escaped, separately marked as data, or restricted to trusted constants. internal/fence/fence.go:30–34 places both arguments verbatim in the introductory sentence before the second sentinel, allowing instruction text and newlines there without sentinel forgery. The first sentinel precedes this metadata, so describing it as outside every fence would be inaccurate, but that does not refute the stated possibility that a model treats preamble text differently from the content block. The hardening disclaimer at lines 3–7 limits security guarantees rather than preventing this input. No model behavior was executed or established; the finding's conditional 'may consider' claim remains unrefuted.
ref f9a996461134b8b0eb0ded6777120109f34ec6d2dca83b5378457f267da24299#R2
Recorded so that "found nothing here" can be told apart from "never looked here".
The fence implementation correctly neutralizes sentinels within the main `content` body and uses a constant format string preventing format attacks. However, it critically fails to sanitize the `label` and `provenance` arguments (Finding 1). Since these arguments are injected into the preamble before the inner fences, an attacker controlling them can not only break the fence structure by forging sentinels but also inject commands directly into the preamble outside the protected 'DATA' block, bypassing the LLM's instructions to ignore them (Finding 2).
R1 stands: metadata is interpolated without sentinel sanitization. R2 also stands as a possible prompt-injection path, although neither finding demonstrates successful manipulation of an LLM. The review's overall assertion of a bypass is stronger than its evidence.