An administrator credential for the one account holding all three products leaks - what is inside its blast radius?

## "Everything inside" is the answer, and it is bigger than it sounds The account is one isolation boundary, so a credential with full rights in it is standing over the whole container. The useful part of the answer is the enumeration, because candidates reliably list the compute and stop. ### What is inside - **Every resource in the account**, across all three products - including the ones nobody remembers creating, which is most estates' worst category. - **The data at rest.** Platform encryption typically protects bytes against everything *outside* the account and decrypts transparently for authorised principals *inside* it. Encryption at rest answers "what if someone takes the disk", not "what if someone takes an administrator credential". Key custody arrangements change this picture, but the default does not. - **The audit record of management API calls.** It records what the intruder did, and rights broad enough to do the damage are usually broad enough to stop it being recorded or to delete what was recorded. Evidence living inside the radius it is meant to describe is the structural weakness of a single-account estate. - **The bill.** An account can create expensive resources, in volume, without any further approval - a well-known monetisation of a leaked credential. - **Persistence.** With broad rights, the holder can create new principals, new credentials and new trust relationships. These outlive the rotation of the credential that made them. - **Anything reachable from inside** the account's private networks, including systems elsewhere that trust traffic from those networks. ### What is outside - **Other accounts**, unless a trust was already set up between them - which is exactly the property that makes a second account a boundary and not just tidier bookkeeping. - **The provider's own platform and its other customers.** A leaked credential is scoped to your account; it is not a foothold on the provider. - **Anything guarded by a credential the account does not hold** - an external payment processor, a code host, a partner system with its own authentication. ## Why the containment question is really a boundary question | Asset | What the leaked credential can do | What would have limited it | |---|---|---| | Product data in a store | Read, copy, delete | The asset sitting in a different account with no trust to this one | | The audit record | Read, often disable or delete | The record streamed out of the account as it is written | | Backups held in the account | Delete along with the primary | Copies outside the account, or retention the account cannot shorten | | Spending | Create resources freely | Nothing inside the account - it is the same payer | | New principals | Create at will | Nothing inside the account - it is the same administrator set | Read the right-hand column and a pattern falls out: every meaningful limit involves something *not being in the account*. That is the whole reason estates eventually stop being one account. The mechanics of arranging several accounts, and of the restrictive layers that sit above them, belong to neighbouring subjects; what this one establishes is why that pressure exists at all. ## Responding, and why rotation is not the end 1. **Rotate and revoke**, including the founding sign-in that opened the account and any long-lived credential attached to a workload. Short-lived credentials already in flight expire on their own, which is one argument for them. 2. **Hunt for persistence.** New principals, new credentials, new trusts, changed automation. This step is what people skip, and it is why an incident recurs a week later with nothing apparently changed. 3. **Reconstruct from the audit record**, and note honestly what it does *not* cover - anything deleted, anything done before recording was enabled, and data-path reads that the management-plane record never sees. 4. **Check the spend**, which is often the fastest detector of a compromise nobody noticed. 5. **Recover from copies the account cannot reach.** If the only copy of the data sits in the compromised account, you are trusting an attacker's restraint. A last accuracy point, because it is easy to overstate: this is not "the provider is compromised" and it is not "every environment is gone". It is that within one account, isolation, evidence, recovery and spend all share a single administrative fate. Stating that precisely - rather than reaching for the word "everything" and stopping - is what separates a senior answer from a confident one.