Who is accountable when object references expose another user’s data?

Accountability is shared across application owners, IAM teams, and security engineering because the failure sits at the join between identity, workflow design, and data access. Controls like access review, secure code review, and runtime authorisation testing all matter, but the owning team must prove object-level entitlement.

Why This Matters for Security Teams

Object reference failures are not just a coding mistake. They are an accountability problem that spans application ownership, identity governance, and data protection. When an application can fetch another user’s record by changing an identifier, the real failure is that object-level entitlement was never proven. NHI Management Group’s research shows that many organisations still struggle with basic identity visibility and control, which makes these issues harder to detect and contain.

The risk is amplified when service accounts, API keys, or backend jobs are allowed to act broadly without proving which object they are allowed to touch. The Ultimate Guide to NHIs — Key Research and Survey Results notes that 97% of NHIs carry excessive privileges, which helps explain why data exposure persists even when perimeter controls look healthy. Security teams should treat this as a join problem between identity, workflow design, and runtime authorisation, not as a single-team defect. In practice, many security teams encounter broken object-level access only after a customer reports seeing another user’s data, rather than through intentional testing.

How It Works in Practice

Accountability starts with assigning ownership to the team that designs and operates the workflow, because that team controls the object lookup path, the entitlement logic, and the data returned to the caller. Application owners are responsible for proving that every object reference is checked against the caller’s identity or delegated authority. IAM teams support the identity side, but they cannot compensate for missing object-level checks in application code or API gateways.

Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports strong access enforcement, auditability, and least privilege, but implementation still has to happen inside the application request path. For NHI-heavy systems, the operational pattern is:

• Bind each request to a verified identity, including service accounts and automation.
• Check object-level entitlements at runtime, not just at login or token issuance.
• Log the actor, object, decision, and policy reason so incident teams can trace exposure.
• Test for IDOR and related object reference flaws during secure code review and release gates.

NHIMG’s 52 NHI Breaches Analysis is useful here because it shows how identity failures often cascade into broader access exposure when entitlements are too broad or poorly governed. The practical accountability model is simple: the app team owns the object check, IAM owns the identity foundation, and security engineering validates the control design and evidence. These controls tend to break down in legacy monoliths and shared-service APIs because object ownership is implicit, entitlements are inherited, and no single system can prove who should see which record.

Common Variations and Edge Cases

Tighter object-level control often increases engineering and support overhead, requiring organisations to balance stronger isolation against delivery speed and system complexity. That tradeoff becomes visible in multi-tenant platforms, delegated admin flows, and background jobs that legitimately need broad read access.

There is no universal standard for every edge case yet, but current guidance suggests treating exceptions as explicit policy decisions rather than informal shortcuts. For example, a support analyst may need temporary access to a customer record, but that access should be time-bound, logged, and approved. Automated workflows should use the minimum object scope possible, even when the underlying credential is powerful. The Ultimate Guide to NHIs — Why NHI Security Matters Now is especially relevant for teams trying to reduce standing privilege across machine-to-machine paths.

One more edge case is outsourced or federated development, where code ownership and runtime ownership sit with different groups. In those environments, accountability should be written into release approvals, API contracts, and access review evidence so no team can assume another team is validating the object check. The strongest programs pair secure design reviews with runtime authorisation testing because either one alone can miss entitlement drift after deployment.

Related resources from NHI Mgmt Group

• Who is accountable when AI data is processed in another jurisdiction?
• Who is accountable when support workflows expose customer data across tenants?
• Who is accountable when vendor telemetry exposure reveals AI user identity data?
• Who is accountable when backup privileges expose protected Windows data?