Who is accountable when a user can see or edit data outside their organization?

Why This Matters for Security Teams

This question usually surfaces when a control failure is not about login, but about authorization boundaries. If a user can view or edit data outside their organization, the core issue is that tenant isolation, object-level checks, or inherited permissions were not enforced consistently on the server. NIST SP 800-53 Rev 5 security and privacy controls treat access enforcement as a core security responsibility, not a UI feature, and NHIMG research shows how often identity and access weaknesses are exploited in practice. The Ultimate Guide to NHIs — Key Research and Survey Results notes that 97% of NHIs carry excessive privileges, which is a warning sign for any environment that relies on broad trust relationships.

Accountability sits with the application team because the application defines the authorization boundary, even when authentication is outsourced to an identity provider. Security teams should focus on whether every sensitive read and write is checked against tenant context, ownership, and policy at request time. In practice, many security teams encounter cross-tenant exposure only after a customer reports it, rather than through intentional boundary testing.

How It Works in Practice

Correct accountability means the team shipping the application must prove that authorization is enforced where data is accessed, not just where a session is created. The identity provider can assert who the user is, but it does not decide which records, tenants, or actions are in scope. That decision belongs in the service layer, data access layer, or policy engine, using rules that evaluate the current user, tenant relationship, object ownership, and action type. NIST guidance on access control in NIST SP 800-53 Rev 5 Security and Privacy Controls supports this separation of duties.

In a healthy design, the application does not trust a client-supplied tenant identifier or role claim by itself. Instead, it resolves the effective tenant from server-side context, checks whether the requested record belongs to that tenant, and logs the decision. This is especially important for APIs, background jobs, and admin tooling, where UI restrictions can be bypassed. NHIMG’s research on credential and access misuse shows why visibility alone is not enough without enforceable boundaries, including the JetBrains GitHub plugin token exposure case, where exposed tokens could have extended access beyond intended scope.

• Enforce object-level authorization on the server for every read, write, and export.
• Bind records to a tenant, project, or organization identifier that cannot be altered by the client.
• Use policy checks for inherited permissions so group membership does not overextend access.
• Record authorization decisions in audit logs to support incident response and policy reviews.
• Test cross-tenant access explicitly in QA and pre-production, not only during annual reviews.

These controls tend to break down when the application mixes tenant data in shared tables without a reliable ownership key because the service cannot make a deterministic authorization decision.

Common Variations and Edge Cases

Tighter authorization often increases engineering overhead, requiring organisations to balance fast delivery against stronger tenant isolation. Best practice is evolving around how much should be handled by central policy engines versus embedded service logic, and there is no universal standard for this yet. The right answer depends on whether the system is a multi-tenant SaaS product, an internal portal, or a federated platform with delegated administration.

Edge cases often appear where permissions are inherited from parent accounts, where support staff need temporary break-glass access, or where data is replicated across regions and services. In those environments, security teams should treat “who can edit” as a separate control question from “who can see,” because write access usually creates a higher blast radius. A user who can read outside their organization may expose privacy data, but a user who can edit outside their organization can also corrupt records, alter approvals, or create fraudulent workflows. NHIMG’s Code Formatting Tools Credential Leaks research is another reminder that hidden trust paths and unattended permissions often become the real failure point.

Where guidance becomes less settled is in delegated administration and customer-managed access models. Current guidance suggests treating these as explicit policy exceptions with time limits, separate logging, and regular review, rather than as informal “trusted” paths. That approach keeps accountability with the application team while still allowing business exceptions to function safely.

Related resources from NHI Mgmt Group

• Why is it important to integrate identity and data governance?
• When do service accounts become a higher risk than ordinary user accounts?
• Who is accountable when an AI system moves data outside policy?
• Who is accountable when sensitive data is shared outside approved scope?