Data isolation and ACLs: why multi-tenant systems leak customer records

A software defect introduced during an overnight IT update to the Lloyds Banking Group mobile platform stripped the per-customer query scope filters from the API layer. On 12 March 2026, customers logging into the Lloyds, Halifax, and Bank of Scotland apps began seeing transaction records belonging to other account holders. The breach was not theoretical. Up to 447,936 people were affected. Of those, 114,182 clicked on exposed transactions and potentially read account details, National Insurance numbers, and salary data that were not theirs to see.

That is a multi-tenant data isolation ACL failure in production, at scale, in a regulated financial context. The mechanism is one that security engineers who work with shared platforms or build API proxies in a homelab will recognise immediately.

What actually broke and why three banks felt it simultaneously

Lloyds Banking Group operates Lloyds, Halifax, and Bank of Scotland on a shared mobile platform. A single software update touched all three. When the defect removed the identity-scoped query filters, it did so across every brand at once, because the same codebase served all of them. The blast radius was not three separate incidents. It was one ACL regression with three visible faces.

The defect sat in the mobile API layer. Authenticated sessions were still valid; the authentication mechanism itself did not fail. What failed was the step that should follow authentication: asserting the tenant context before issuing a query. The API was returning transaction data without first confirming that the requesting identity matched the identity whose records were being fetched. A logged-in session token was treated as sufficient authorisation to retrieve any data the query could reach.

This is a classic access control failure. The authenticated session and the authorised scope are two separate checks. Collapsing them into one, or assuming that a valid session token implies correct scope, is the exact condition that produces this class of breach.

The structural problem with presentation-layer boundary checks

The gap Lloyds disclosed was between transaction display and the identity-scoped access check that should precede it. That framing matters. It suggests the scope check existed at the presentation layer, not at the query layer. When a software update modified how the API assembled and returned data, the check did not travel with it, because it was not enforced at the point where the query was built.

Row-level security and customer data boundary checks applied only at the presentation layer are not access controls. They are display filters. A display filter can be removed, overridden, or simply forgotten when the rendering logic changes. An access control at the query or data layer cannot be bypassed by a UI change, because the restriction is enforced before any data leaves the database or the service layer.

The correct pattern is: the query itself must carry the tenant identifier, and the data layer must reject or filter any query that lacks it or presents one that does not match the authenticated principal. If you are building this in any context, the tenant context must be asserted at the query layer. Relying on the session token alone to implicitly scope results is insufficient.

Why this survived testing

Access control failures of this type survive internal testing for a predictable reason: test accounts often share the same tenant fixture. If your CI pipeline authenticates as a test user and queries a test data set that belongs to that same test user, you will never observe cross-tenant leakage. The regression only becomes visible when a real authenticated session returns results belonging to a different identity, which requires two distinct tenants to be present in the same test run, with a query that crosses the boundary.

Staging environments that mirror the production schema but use a single synthetic tenant cannot catch this. You need explicit cross-tenant boundary tests, where one authenticated identity attempts to retrieve data scoped to a different identity, and the expected result is a rejection or an empty response, not partial data.

Compounded exposure on shared platforms

A single ACL regression on a multi-brand, shared-platform architecture does not produce a single breach. It produces one breach per brand running on that platform, simultaneously. The Lloyds incident confirms that when the access control logic is centralised, so is the failure mode. Three separately branded products with separate customer bases exposed records at the same moment because they shared one API layer.

This is worth considering any time you build or evaluate a platform that serves multiple distinct contexts from a single codebase. The efficiency of a shared platform and the isolation of tenant data boundaries pull in opposite directions if the access control model is not explicit and enforced at the layer that handles data retrieval.

The homelab parallel

A single-node homelab running a multi-tenant API proxy reproduces this risk at a smaller scale. If you are running something like a self-hosted API gateway that routes requests to backend services for different projects or users, and you are relying on the authenticated session to implicitly scope which data gets returned, the structure of the problem is identical to what Lloyds experienced.

The scale is different. The exposure is not. An unscoped query that returns records beyond the requesting identity’s boundary is an unscoped query, regardless of whether it serves 447,936 people or four. The fix is the same: assert the tenant or user identifier at the query layer, not at the layer that renders the response. If your API constructs a database query using only WHERE account_id = <session_user> after authentication but before a separate authorisation check confirms that <session_user> is genuinely entitled to that account_id, you have a gap.

Disclosure timing and what the ICO’s involvement signals

The incident occurred on 12 March 2026. The scale of exposure, 447,936 affected accounts and 114,182 confirmed data accesses, only became public when Lloyds responded to a formal request from the Treasury Committee’s Dame Meg Hillier, who described it as an “alarming breach of data confidentiality.” The ICO confirmed it was examining the incident. By the time those figures were published, the event was fifteen days old.

That timeline is the detection and disclosure problem sitting alongside the technical one. The access control regression was present and exploitable during normal, authenticated user sessions. Customers discovered it by seeing wrong data on their screen. The breach was identified by users, not by automated scope-check monitoring on the API layer. If you are not logging and alerting on queries where the returned tenant context does not match the requesting identity, you will find out the same way Lloyds did.

Compensation of £139,000 to 3,625 affected individuals at an average of roughly £40 each says something about how the remediation calculus was framed. It says very little about what it costs to build and maintain access control that does not rely on a presentation filter surviving an overnight deployment.