Your browser-provider account key leaked — what stays reachable after you revoke it?

## What revocation actually retracts Revoking or rotating a browser-provider account credential invalidates that value for **future authentications**. That is a real and necessary control, and it is also the entirety of what the act itself accomplishes. Everything else that a leak put in motion is either already finished, still in flight, or unknowable — and each of those needs its own response. For a law firm's document-review suite the distinction is not academic. The evidence a run leaves behind is a picture of client material, so the question "what stays reachable" is the question the firm will actually ask. ## What a new key does not undo - **Work already done.** Anything the holder fetched — a recording, a log, a downloaded file — is on their machine. No provider-side change reaches it. - **Sessions already open.** A running session may keep being driven, and it keeps consuming until it is torn down or the far side ends it. - **Identifiers already shared.** Session identifiers, run references and links copied out of reports remain valid names for the artefacts they point at. - **Attribution you never had.** A shared account cannot tell you which holder did what, and rotating it does not retroactively create that record. The in-flight case has an open attestation worth knowing, because it is the one people assume away. In Ggr (unmaintained by its own README), the route that creates a session is wrapped in the authenticator, but the route that carries every subsequent command for an existing session is registered **without** that wrapper: commands are dispatched on a prefix of the session identifier. So in that implementation, removing an account does not retract a session the account already started — it is driven by its identifier, not by the credential. Whether any particular hosted provider behaves that way is not something you can assert from outside; that it is a plausible and implemented design is exactly why you check rather than assume. ## Attribution is the part that hurts Identity in these systems is whatever the caller presented. Selenoid (unmaintained) reads the basic-auth username from the request purely to label its log lines and writes `unknown` when no credential was supplied; Ggr (unmaintained) does the same and substitutes its guest account name when guest mode is on. The general shape follows: **a record can attribute no more finely than the identity that was presented.** When a nightly suite, every pull-request run and an engineer's local experiment all authenticate as the same account, every line reads the same, and the record answers "which account" when the incident needs "which holder". That is why the incident response after a browser-cloud key leak is usually reconstruction rather than lookup, and why the answer to "what did they do" is often "we can bound it, not enumerate it". ## The response that actually bounds the damage 1. **Rotate first**, and confirm the old value fails, because a rotation nobody verified is a belief. 2. **End what is running.** Enumerate open sessions and close them deliberately rather than waiting for a timeout; an abandoned session keeps consuming capacity you pay for. 3. **Enumerate the radius.** List every surface that credential reached — session creation, the web surface, run history, stored artefacts, the live view, entitlement information — and treat everything readable there as read. 4. **Assess by content, not by suspicion.** Decide what those runs put on screen and in their logs. For a document-review suite that is the client material question, and it is answered from your own fixtures and your own capture settings, not from the provider. 5. **Delete what you can and should**, and record what could not be deleted. 6. **Fix the attribution gap**, so the next incident is a lookup: distinct credentials per team or pipeline, each with its own record. | the reflex | why it is not enough | |---|---| | "we rotated, so we are clean" | rotation closes new access; it recovers nothing already taken and ends nothing already running | | "the logs will tell us" | a record resolves to the identity presented, which on a shared account is the same name for everyone | | "identifiers are unguessable" | they are printed into CI output and reports by design, so they are reachable rather than secret | ## What a senior answer sounds like The mark of the answer is that it separates the control from the consequence. Revocation is a control on future access. The consequences of a leak — copied artefacts, live sessions, spent capacity, unattributable history — are separate problems with separate fixes, and none of them is solved by the new key. - Say what rotation stops, in one clause, and move immediately to what it does not. - Name the in-flight session as its own problem, and say you would close sessions explicitly. - Say that you would bound the exposure by content you control, since a closed provider's internals cannot be asserted. - Finish on the structural fix, which is narrowing what any single credential can reach next time. Answering "we rotate the key and move on" is the failure mode. It is the right first step described as if it were the whole response.