How can your own compromised tenant administrator reach a provider's other client estates?

## Two directions, one relationship A managed-service relationship is drawn in almost every diagram as an arrow from provider to client: the provider holds rights, so the provider is the risk. That arrow is real, and it is only half the picture. The other half: **the client is untrusted input to the provider.** The provider's engineers do not administer your estate from a sealed room; they come inside it. They sign in with a privileged identity, open things you control, act on requests you raise, and run work in an environment whose contents you determine. Anything a compromised client can do to a visiting privileged identity is done to an identity that will next be used somewhere else. ## What the reverse path actually looks like The mechanisms are unglamorous and mostly consist of the client's environment being hostile to a guest: - **Consent and grant.** A privileged visitor can be asked to approve an application, accept a delegation, or grant rights the client's own admins cannot self-grant. A hostile client tenant can present that request at exactly the moment the engineer is doing routine work and expecting approval prompts. - **Authenticating into client-controlled ground.** Any place inside the client estate where the provider's identity authenticates is a place the client's owner influences. The credential is presented to something the client, not the provider, controls. - **Rights left behind that the provider keeps using.** A principal, automation identity or shared account inside the client tenant that the provider treats as its own working context can be quietly re-pointed by whoever owns the tenant. - **Work the engineer will pick up.** Requests, scripts and change items originate on the client side. A hostile client supplies the task; the provider's privilege executes it. Note what is *not* on this list: reading the other clients' data out of your tenant. You cannot, and that is precisely why the reverse direction gets missed. ## Why per-tenant isolation is the wrong reassurance The standard comfort is that tenants are isolated: client 47 cannot see client 48's directory or data. True, and irrelevant to this path. The boundary the attack crosses is not the data boundary. It is: - **a shared identity** that is deliberately entitled in every tenant, and - **a shared human** who is deliberately present in every tenant. Isolation was built to stop tenants reading each other. It was never built to stop a tenant influencing something that legitimately traverses all of them. Asserting isolation against this is answering the wrong question, and it is the specific wrong answer worth being able to name. ## The uncomfortable consequences 1. **Your exposure includes the provider's weakest client.** You never chose them, never assessed them, and in most arrangements are not told who they are. They are nonetheless one hop from you. 2. **Their exposure includes you.** If your tenant is compromised, you are the hostile input in somebody else's supply of privilege. This is a duty you have to strangers, and it rarely appears in anyone's risk register. 3. **The provider's own security is a client-facing problem.** Whether the engineer's workstation, credential and session survive contact with a hostile client is a property of the provider's operating model, not of any one client's controls. ## What actually blunts it The controls point at the shared-ness rather than at the data: - **Per-client credentials.** An identity that reaches only its assigned clients turns one hop into no hop. - **Privilege that exists only during an approved engagement.** A visitor who holds nothing between jobs is worth much less to capture. - **A dedicated administrative identity that never touches client-controlled ground for anything else** — no mail, no browsing, no general-purpose use. - **Phishing-resistant authentication** such as FIDO2 or WebAuthn on that identity, which removes the value of capturing a credential presented inside a hostile tenant. - **Approval for consent and role grants that cannot be satisfied by the visiting engineer alone**, so a client cannot convert a visit into a durable grant. ## How to say it in an interview The compact version is one sentence: *tenant isolation stops clients reading each other, but the provider's engineer is a shared identity walking between rooms, and anything one room does to that identity leaves with them.* Then name the direction explicitly — client to provider to peer clients — because naming it is what distinguishes a candidate who has actually thought about the relationship from one who has memorised the provider-to-client story.