Administrative Path Blindness

The per-tenant read path in a multi-tenant system is usually well protected, because it was designed with tenancy as a first-class concern. The internal dashboard, the support tool, the analytics job and the data export were written by people solving a different problem, and they routinely have unrestricted access to everything.

That asymmetry means the access model is rigorous against external attackers and permissive against the paths an insider or a compromised employee account would actually use.

Why it matters

Support access is broad by necessity — an engineer helping a customer needs to see their data — and it is the least covered by customer-facing controls. It is also the path most likely to be exercised routinely, which makes anomalous use hard to distinguish from normal use without deliberate instrumentation.

For a platform holding identity, payroll, financial or health data, this is frequently the largest unaddressed risk in an otherwise mature security programme.

Implementation patterns

• The same enforcement layer applies to internal paths. Row-level security, tenant context and authorisation checks are not bypassed because the caller is a staff tool.
• Just-in-time elevation with an expiry, an approval and a recorded justification, rather than standing broad access.
• Customer visibility into staff access to their tenant. Uncomfortable, and it is what converts a policy claim into a verifiable one — and it makes the control self-enforcing, because staff behave differently when access is visible to the customer.
• A separate audit trail for administrative access, exported outside the platform's own trust boundary so detection does not depend on the system being investigated.
• Thresholds on bulk operations. Mass export and mass deprovisioning are the highest-damage actions available, and both should require confirmation above a proportion of the population — the same safety threshold that protects against a faulty sync also protects against a malicious one.
• Analytics and reporting reading from a governed dataset with tenancy preserved, rather than from production with an unrestricted credential.

Industry example

Platforms such as WorkOS, Rippling and Deel hold exactly the data that makes this acute — identity, employment, payroll, downstream system credentials — and their customers' security reviews increasingly ask about internal access specifically rather than about the customer-facing model, which is a reasonable evolution.

Failure scenarios

• Support tools with a shared privileged credential, making access unattributable.
• Analytics jobs reading production with unrestricted access, then landing results somewhere less protected.
• Standing elevated access, so no approval or record exists for any individual use.
• Administrative audit stored inside the platform, and therefore reachable by whoever is being audited.
• No thresholds on bulk export, so exfiltration looks like a large report.

Trade-offs

Just-in-time elevation and approvals slow down support, which has a real customer-experience cost during an urgent issue. Customer-visible access logs generate questions that consume support time.

The counter-argument is that the alternative is an unbounded insider risk on the most sensitive data in the product, and that the friction is proportionate to what is being protected. The usual compromise is tiered: read access to non-sensitive fields is standing, access to sensitive fields is elevated, and any export is approved.

Interview question

"Your customer-facing authorisation is watertight. Tell me how one of your support engineers could obtain a copy of a customer's entire dataset, what would stop them, and what record would exist afterwards."