Several teams share one browser-provider account — what does that couple together?

## One account is one of everything When several teams authenticate to a hosted browser provider as the same account, the account becomes a single point through which unrelated things are forced to agree. The word people reach for is "sharing a key", which understates it: what is shared is not the string, it is every consequence attached to the identity that string proves. - **One entitlement.** Whatever the account may ask for, every holder may ask for. - **One pool of capacity and one bill.** Consumption by any holder is consumption by all of them. - **One artefact set.** Evidence produced by any holder's runs sits where every holder can look for it. - **One identity in the record.** Activity resolves to the account, so it resolves to everyone. - **One revocation switch.** A leak anywhere forces a rotation that interrupts everyone. That last pair is the part teams discover late. Separation is not something the shared credential gives you and you then lose by carelessness; it is something to arrange deliberately and then verify. ## The readable attestation Ggr, unmaintained by its own README, implements the entitlement half in source you can check. An account's entitlement is an XML file **named after the account**, one per account in the directory of entitlement files the router loads at start-up, and the router looks it up by that account name when a session is requested. That directory is a different artefact from the credential store the same router authenticates against, which is worth keeping straight: one file says who may call, the other says what the caller may ask for. There is no subdivision below the account: another pipeline authenticating with the same name gets the same catalogue of browsers, versions, regions and hosts, and the router has no way to tell the callers apart. Its entitlement-reading route reflects the same design — it returns the catalogue belonging to whoever is calling, and it explicitly blanks the per-host username and password fields before replying, because that catalogue can itself carry credentials for the services behind it. That detail is worth carrying into any discussion of blast radius: **a surface a key opens may contain other secrets**, and whether they are redacted is a decision someone made in code rather than a property of the design. Identity in the record follows the same logic. Selenoid (unmaintained) and Ggr (unmaintained) both take the username for their log lines straight from the credential the caller presented, writing `unknown` or a guest name when none was. A record cannot attribute more finely than the identity presented, so a shared account produces a history in which the nightly run, every pull-request run and every engineer's local experiment wear the same name. ## What separation costs and what it buys For a law firm's document-review workspace, the concrete question is whether the team that runs the matter-intake suite should hold the same credential as the team that runs the billing-portal suite. | shared account | credential per team | |---|---| | any holder's leak can expose every team's recordings | a leak exposes one team's recordings | | any holder's misuse of capacity starves the others | contention is visible and attributable | | the record names the account, so incidents need reconstruction | the record names the team, so incidents start as a lookup | | one rotation interrupts everybody | rotation is scoped to the team that needs it | | one secret to manage | more secrets to manage, each narrower | The right-hand column is not free — more credentials means more to store, distribute and retire, and that is the honest trade to state at interview. It is still usually the better trade, because the cost is administrative and steady while the benefit is that no single leak is total. ## What you can ask for, and what you cannot assume You cannot assert what any particular closed provider separates internally, what its arrangements are called, or what a given account structure enforces. What you can do is ask, test and record. 1. Ask the vendor, in writing, what per-team or per-pipeline separation is available, and whether a credential can be narrowed to fewer surfaces than the account has. 2. Test what a credential actually reaches from a clean machine, rather than reading a description of it. 3. Give each pipeline its own credential wherever the provider allows it, even when the entitlement behind them is identical, so that revocation and attribution become per-pipeline. 4. Keep an inventory of which credential belongs to which team, so that a leak has a known scope on the day it is found. 5. Re-test after any account change, because what the account reaches can widen quietly. ## The sentence to have ready Sharing a browser-provider account fuses entitlement, capacity, artefacts, attribution and revocation onto one identity, and none of those separates by itself. The remedy is not better handling of the shared value — careful handling of a credential that reaches every team's surfaces still reaches them — it is a narrower credential per team, obtained by asking the provider what it offers and verifying what the result actually opens.