Notifications
Clear all
Topic starter
11/06/2026 11:55 pm
TL;DR: Uber’s “God View” story illustrates how broad internal access, brittle role checks, and weak auditability turn admin panels into privacy and compliance liabilities, according to Cerbos. The underlying problem is not bad users, but authorization models that cannot express context, constrain scope, or prove who saw what.
NHIMG editorial — based on content published by Cerbos: a guide to reducing internal-tool risk through policy-based authorization
Questions worth separating out
Q: How should security teams govern access to sensitive data in internal tools?
A: Treat internal tools as high-risk systems when they expose personal, financial, or operational data.
Q: Why do broad support dashboards create security risk?
A: Broad support dashboards create risk because they let a user see far more data than the immediate task requires.
Q: What breaks when authorization logic stays in application code?
A: When authorization stays in application code, policy becomes hard to audit, hard to update, and easy to copy inconsistently across services.
Practitioner guidance
- Map your internal God View systems Inventory admin panels, support dashboards, export tools, and operational consoles that expose sensitive user or customer data.
- Replace coarse roles with context-aware policy Move the highest-risk decisions to centrally managed rules that can evaluate ticket assignment, customer ownership, region, and purpose at request time.
- Log every privileged data decision Record principal, action, resource, policy outcome, and justification for views, exports, and deletes.
What's in the full article
Cerbos's full guide covers the operational detail this post intentionally leaves for the source:
- A concrete pattern for extracting authorization logic from application code and centralising it in policy files.
- A stepwise approach to turning one risky action, such as data export or record deletion, into a controlled decision path.
- Practical guidance on making policies readable enough for security, legal, and compliance review without developer translation.
- Implementation examples that show how a decoupled authorization service fits into existing application workflows.
👉 Read Cerbos's guide to internal authorization and policy-based access control →
God View-style internal access: what IAM teams are missing?
Explore further
12/06/2026 8:49 am
Broad internal access is a governance failure, not a convenience feature. The God View pattern shows what happens when organisations treat internal access as inherently lower risk than customer-facing access. That assumption fails because internal users can still misuse broad visibility, and the business impact is the same privacy breach, reputational damage, and regulatory exposure. The implication is that internal tools need the same least-privilege discipline as any other high-value system.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, which shows how often remediation windows stay open long after discovery.
A question worth separating out:
Q: Who is accountable when an employee misuses internal access?
A: Accountability sits with the organisation if it granted broad access without sufficient controls, evidence, and review. A usable governance model must show who approved access, who exercised it, and what was logged. Without that chain, organisations cannot separate policy failure from individual misconduct.
👉 Read our full editorial: Internal tools need dynamic authorization, not broad admin trust
