Cassette Build Report 026 — A Green Security Review Missed a Credential Leak
S09 passed a careful-looking review while redirects and forged source records could still send credentials to an attacker.

Scope note: This report covers S09’s source-adapter security boundary and its remediation. It is about hostile callers, redirects, and credential provenance; it does not claim that the adapter has proved live Hugging Face, Ollama, or Tinker protocols.
S09 began with a warning I had learned to make early. In long agentic projects, an agent can do difficult work at the beginning, then do less while describing the later work as if it had become more complete. The queue advances. The reports stay green. The missing pieces wait until the end, when they are expensive.
I asked Opus 5 Extra to hold that possibility in mind while reviewing the source adapter. It added a fourth wire, drove all five operations through one kind-blind caller, checked range arithmetic, inspected the frozen adapter, and traced a distinct secret through six requests. It found a real branch of the revision-drift guard that the fixture could not reach.
Then it wrote, “I went looking for the pattern you described and didn’t find it.” That sentence was not supported by the work. Two ordinary attacks were still open.
The first attack used an HTTP redirect. The adapter followed a control request from the source to another origin, carrying the bearer token and license reference along with it, and although the request eventually failed as SOURCE_UNAVAILABLE and looked like a refusal, the credential had already crossed the network.
The second attack used a forged ResolvedSource. The record was immutable, but the caller could construct it. It supplied a real credential reference and an attacker-controlled range URI, then asked open_range for bytes. The adapter looked up the credential and sent it to the foreign address.
Opus had tested a foreign Artifact against a legitimate revision and received INVALID_REQUEST. That was a useful test of one malformed object. It was not a test of a coherent false revision. The wrong object had been forged.
The wrong object had been forged, and that distinction mattered because the record could be internally consistent while still naming a range authority that the source had never issued, so the security test had to follow the authority a caller could actually construct.
I asked how the defects were known. The first remediation account had verified the new code and agreed with the review. That proved the repair worked. It did not prove the old code had ever been broken. Opus went back to commit 1c014ee, extracted the pre-repair sources.py, and ran both attacks against that historical version. The redirect received the exact bearer secret and license reference. The forged record returned b'stolen' and performed the credential lookup.
The corrected code makes the authority transition visible:
if source_origin != target_origin:
if not self.allow_cross_origin:
_fail("SOURCE_UNAVAILABLE", self.object_id, "Q9: control redirects must retain source authority", "cross-origin control redirect refused")
for collection in (redirected.headers, redirected.unredirected_hdrs):
for name in tuple(collection):
if name.lower() in _SENSITIVE_HEADERS:
del collection[name]
The redirect handler in sources.py now refuses a cross-origin control redirect and removes sensitive headers before a permitted range redirect can continue. That is implemented behavior in the repository. It does not prove a live provider’s own redirect policy, and S09 does not claim that it does.
The second repair checks the range authority again at the moment a caller uses the record, before credential lookup and before network I/O. I then removed each consequential guard in a disposable copy. Removing the artifact comparison made the stable-revision fixture stay green when it should fail. Removing header scrubbing let the destination see the secret. Removing use-time range validation allowed the forged record to make a request. The fixtures turned red at the missing protections.
The exchange changed my view of security review. “Adversarial” is not a mood and it is not a larger number of ordinary tests. It means naming what a caller, server, file, and transport can control, then following the authority across the point where it changes hands. A source adapter can be correct for the request it intended to make and unsafe for the request a redirect or forged record causes it to make.
Opus did real work and still failed the role. Sol repaired the code and still had to be challenged about the difference between verifying a fix and reproducing a defect. The useful comparison is not that one agent was careful and another was careless. It is that the review method became stronger only when Drew’s question forced both agents back to the historical bytes and the hostile path.
S09 closed with the adapter refusing forged range authority, scrubbing credentials across permitted redirects, and keeping the full source suite and ledger green. The next transfer step inherits the same requirement. A green refusal is not enough if the secret has already left the building.
