A rendering service runs code written by strangers. That is not an edge case or a threat model exercise — it is the product. Someone hands you a URL, you fetch it, and whatever JavaScript is on the other end runs inside your infrastructure, on your network, with whatever reachability that network happens to grant it.
Which makes one question the most important one in the whole system: what can that browser reach?
The sentence that could not be demonstrated
Our architecture documents answered it. They said the browser's egress was contained. The sentence had been true when it was written, it had been repeated in several places since, and by the time anyone went looking, nobody could produce the evidence for it against the deployment that was actually running.
That is the ordinary way this goes wrong. Nothing is falsified deliberately. A control is designed, described, and partially implemented; the description survives into the next document unchanged; the implementation drifts; and the gap is invisible because documents do not fail tests.
What we did about it
We disabled public capture.
Not "opened a ticket". Not "added a note to the risk register". The feature that could not be shown to be contained stopped being available to the public until it could be, and the reason was published rather than described internally as maintenance.
This is worth stating plainly because it is the part that is easy to skip. Turning off a working product to verify a property that has not visibly failed is a decision that costs something real and returns nothing visible. There is always a defensible reason to do it next week instead — no incident has occurred, no customer has asked, and the sentence is *probably* still true. That reasoning is exactly how the gap opened in the first place.
What came back
Three things changed before capture reopened.
One boundary, and it fails closed. Every browser launch in production passes through a single authorization boundary. Not a check at each call site — one gate, in one place, which refuses by default. Call sites can forget to check; a gate cannot be forgotten by the code that has to pass through it.
Controls measured, not asserted. The security-controls list was rewritten against what the deployment actually does. Several entries had described the design rather than the deployment, which is a category of documentation error that reads exactly like accuracy.
Unconfirmed means unconfirmed. Alarm delivery without a durable record now reports as unconfirmed rather than as delivered. An alerting path that reports success it cannot evidence is worse than having no alerting, because it converts an unknown into a false reassurance.
The general shape of the mistake
The interesting thing is not the specific control. It is that the failure mode had no symptom.
Everything was green. Tests passed, deploys succeeded, no customer noticed anything, and every document you could read described a system that was correctly contained. The only way to find it was for someone to try to *demonstrate* a claim rather than read it — and the only way that happens is if demonstrating claims is a thing the team does on purpose, on claims that nobody currently doubts.
We now try to write claims in a form that can fail. "Every browser launch passes through this boundary" is a property a test can assert against the source. "Egress is contained" is a sentence.
What this means if you are the one sending the URLs
Practically: the capture service treats the pages it renders as hostile, because they are. It does not treat *your* request as hostile — but it does assume that whatever your URL points at might be, including in the case where your URL is fine and something it loads is not.
That is why some things you might expect to work do not. Requests to private address ranges are refused, redirects are re-checked rather than followed on trust, and the browser's reachable surface is deliberately smaller than the machine it runs on. If a capture is refused for a target you believe is legitimate, that is worth a report through `POST /feedback` — those reports are how the boundary gets tuned without being loosened.
The progress page has the shorter version of this stage alongside the rest, and the docs cover the limits a caller actually runs into.