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. Security engineers who work with shared platforms or build API proxies in a homelab will spot the shape of it straight away.

What actually broke and why three banks felt it simultaneously

Lloyds Banking Group runs 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. This 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 enough authorisation to retrieve any data the query could reach.

This is a classic access control failure. The authenticated session and the authorised scope are separate checks. Treating a valid session token as proof of correct scope is the sort of mistake that produces this breach class.

The structural problem with presentation-layer boundary checks

The gap Lloyds disclosed was between transaction display and the identity-scoped access check that should have come first. That points to the scope check living at the presentation layer, not the query layer. When a software update changed how the API assembled and returned data, the check did not travel with it, because it was not enforced where the query was built.

Row-level security and customer data boundary checks at the presentation layer are not access controls. They are display filters. A display filter can be removed, overridden, or simply forgotten when rendering logic changes. 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 service layer.

The pattern is straightforward: 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 anywhere, the tenant context needs to be asserted at the query layer. Relying on the session token alone to scope results is not enough.

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 see cross-tenant leakage. The regression only shows up when a real authenticated session returns results belonging to a different identity, which needs two distinct tenants 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 tries 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, at the same time. The Lloyds incident shows that when the access control logic is centralised, so is the failure mode. Three separately branded products with separate customer bases exposed records at once because they shared one API layer.

That is worth thinking about any time you build or assess a platform that serves multiple distinct contexts from one codebase. Shared infrastructure and tenant isolation pull in opposite directions if the access control model is not explicit and enforced at the data retrieval layer.

The homelab parallel

A single-node homelab running a multi-tenant API proxy reproduces this risk at a smaller scale. If you are running 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 scope which data gets returned, the structure of the problem is the same as what Lloyds hit.

The scale is different. The exposure is not. An unscoped query that returns records beyond the requesting identity’s boundary is an unscoped query, 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 points to the detection and disclosure problem sitting alongside the technical one. The access control regression was present and exploitable during normal, authenticated user sessions. Customers found it by seeing the 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 depend on a presentation filter surviving an overnight deployment.