Shared Key Blast Radius

## Authenticating and being entitled are different checks Presenting a valid credential establishes *which account is calling*. Deciding that this caller may have *this particular recording* is a separate decision, taken later, against different information — and a remote fleet does not necessarily take it at all. When they are collapsed, the boundary around an artefact stops being the run that produced it and becomes the whole account. That matters concretely for a law firm's document-review workspace. A suite that opens matters, scrolls privileged text and fills forms produces recordings that are pictures of client material. Whether a colleague's credential — or a leaked one — can fetch those recordings is not a detail of the provider's user interface; it is the actual width of the exposure. ## The readable case Ggr, unmaintained by its own README, is the open implementation of exactly this shape, and it is worth reading because nothing about a closed provider can be checked the same way. - Its `/video/`, `/logs/` and `/download/` routes are wrapped in the same authenticator that wraps session creation, so one credential covers artefacts and sessions alike. - The handler behind those routes takes a fixed-width prefix of the requested session identifier, looks that prefix up in its routing table to find the host, and reverse-proxies the request there. - Nothing in that handler compares the calling account against whichever account created the session. There is no per-session ownership record in Ggr (unmaintained) at all; the account name drives an access decision only at session creation, at the entitlement route, and in the guest check that decides whether an unauthenticated caller is admitted — never against the session whose artefact is being fetched. - Its live-view socket route is not behind that authenticator at all, and Ggr's own quota documentation (Ggr is unmaintained) says plainly that having the running session identifier is what gets you the screen. So in that implementation the honest statement is: **the credential is checked at the door, and the artefact is then located by identifier.** An account that started nothing can retrieve what another account produced, given the identifier. ## Why the identifier is not the control A natural response is "then keep session identifiers secret". That is a weak control, because the identifier is engineered to travel: - The harness prints it so a failing test can link to its evidence. - Result reports and dashboards carry it, often into surfaces with wider readership than the pipeline. - Job logs keep it for as long as the logs are kept. - Any annotation or ticket that references the run carries it too. An identifier that is designed to be quotable is not a secret, and a boundary that depends on its obscurity is not a boundary. Treat every session identifier your suite emits as reachable by anyone who can read your CI output. ## What you may assert, and what you must establish Nothing here licenses a claim about a specific closed provider's internal access model. What a vendor separates, what its roles are named and what its web surface shows are not observable from outside, and asserting them is how confident-sounding answers go wrong. What you can do is measure behaviour: 1. Issue or obtain a credential on the account that has started nothing. 2. Take a session identifier from a run started by a different credential on the same account. 3. From a clean machine, attempt to retrieve that run's recording, its log and any file it downloaded. 4. Record each outcome. Repeat for the live view while a session is still open, because a live surface and a stored surface are not always guarded the same way. 5. Put the result in writing, and re-check it after any change to the account. | what you observed | what it means for the suite | |---|---| | the fetch succeeded | the artefact boundary is the account; a credential on it can reach evidence from runs it did not start | | the fetch was refused | a narrower boundary exists today; record how you tested it, because you have shown behaviour and not a guarantee | The second row is the one candidates get wrong. A refusal you observed once is evidence, not a contract, and it is worth re-testing rather than being promoted to an assumption. ## Practical consequences - Decide what the suite is allowed to put on screen *before* the recording exists, because retrieval control is weaker than you would like. - Prefer distinct credentials per team where the provider allows it, so that a retrievable artefact set is at least smaller. - Do not rely on identifier secrecy; rely on what is captured in the first place. - When an exposure is being assessed, count every run whose identifier is discoverable, not only the runs the compromised pipeline started. The short version for an interview: authentication tells the fleet who is calling, and unless something downstream narrows it, the answer to "whose recordings can this key fetch" is "every run the account produced". Go and find out which of those worlds you are in.