In this note
North and South both have a policy document called AP-1. North asks a question first, and the application caches the answer under policy:AP-1. South asks next. The application checks South's login correctly, finds that cache key, and returns North's answer.
The source database could have perfect customer filters and this would still leak data. In this hypothetical design review, I'd follow the customer identity beyond the initial request, especially into cached answers and work that resumes later. A customer organization sharing the service is often called a tenant.
A cache hit still needs an access check
The server must establish the signed-in person's identity and current customer membership through trusted authentication and policy checks. The document name, email domain, or a tenant ID supplied in the message cannot select whose records to use. Use that verified customer in both the source lookup and the cache lookup: North's AP-1 answer and South's AP-1 answer must be separate entries, even though the document names match.
| Design | What it must account for |
|---|---|
| Shared key policy:AP-1 | Wrong: a name shared by two customers can return the first customer's answer. |
| Customer-bound cache entry | Bind the entry to the verified customer, resource and source versions, and the applicable permission and policy context. |
| Read from cache | Check current access and freshness before returning content. A matching key is not an access grant. |
Separating North from South is only the first check. Two people in North may have different document or field access, so North's customer ID alone cannot decide whether they may share an answer. Specify which readers may share each cached entry, and check the requesting person's current permission before returning it. When a document changes, is deleted, or becomes restricted, invalidate or stop serving affected entries under a defined rule. A fresh cache timestamp cannot make an old source current.
Keep customer scope on saved answers, search results, citations, downloadable files, and telemetry too. Even an error naming another customer's document can disclose something. The person investigating a failure needs an approved way to see the relevant customer's evidence; giving every support worker an unrestricted cross-customer dashboard is not a repair.
Check again when a queued job resumes
Alice belongs to North when she requests a policy summary. The job waits. Before it resumes, North removes her membership. A worker with a powerful service account must not treat that account's permissions or the job's saved North label as Alice's continuing authority. This is work delegated by Alice, so the worker must check her current permission before reading more data or returning the result.
Save a trusted link to the initiating person, customer, purpose, permitted resources, and intended recipient when admitting the job. On resume, verify those facts against current policy. Refuse missing, expired, revoked, or widened authority. If a separately authorized unattended service needs to do work for North, give that service an explicit, current grant of its own. Don't silently convert Alice's stopped request into that different kind of job.
If the worker asks another worker to perform a lookup, that child job needs a permission record the receiving service can verify. It must identify the worker allowed to use it and the lookup it permits. Its customer, data, actions, budget, and expiry cannot exceed what the parent job allows. Each receiving service checks that record and current permission; copying tenant:North into a child prompt does not enforce anything. Check permission again before returning the result, not only before the first source read.
| Request to try | Required result |
|---|---|
| South requests AP-1 after North populated the cache | No North content, citation, file, or revealing error reaches South. |
| A person in North requests a resource restricted to another North role | The cache hit still denies the unauthorized content. |
| Alice's membership is revoked while her delegated job waits | The resumed job performs no further unauthorized read or disclosure; an authorized operator receives a minimized blocked-work record. |
| A child job omits or changes the verified customer scope | The receiving service refuses it before accessing or disclosing customer records. |
Trace one customer's work beyond the request
Take a permitted test request and follow it through the source, cache, worker, any child job, returned answer, export, and logs. At each step, identify which trusted check establishes the customer and what happens if it cannot. Check credential and storage configuration as well as application fields. Database filters can add protection, but they cannot stop a separate cache or tool from returning another customer's data.
The worksheet supplies the North/South example and a blank trace. Run the proposed failures against your actual configuration before accepting the result. These paper cases do not establish isolation, revocation speed, or compliance for any platform. Measure how quickly access changes take effect, make that limit explicit, and keep affected work stopped when required authority is unknown.