What to write when they ask if one customer can see another's data

What the row is asking

Reviewers ask how one customer's data stays out of another customer's account. They want the mechanism. The word isolated, with nothing after it, is the answer they reject.

This is a different row from who on your team can open this customer's account. That row uses tenant for this customer's account. This row is whether Customer A's data can be reached from Customer B's account, or from an agent acting for Customer B.

Onplana, on a page dated October 7, 2026, asks "How is one customer's data isolated from another's?" A good answer on that page names "The mechanism, not the word 'isolated'." Onplana writes vendor-review questions. This is their list, not a founder asking for help.

The same page tells a reviewer to "Create a test user with the lowest role and try to reach another project." That is their check. Write the result only if you ran it. This page does not run it.

AuditXYZ, on a page that says Last updated: 2026-07-23, writes: "The same applies to tenant isolation for Tier 1 vendors: a vague answer there ends the evaluation early and cheaply." The same page asks "How do you prevent cross-tenant data leakage through shared models, caches, or embedding stores?" No person byline is on the page. Treat it as that vendor's questionnaire, not as a founder asking for help.

A post on r/SaaS, July 14, 2026, is written as the person selling an AI agent product. A new section asked for "proof tenant a's agent can't touch tenant b's data." They said they would get back to the reviewer, and "the deal sat in procurement for six weeks." The same section also asked for a per-action audit trail and what stops personal data reaching the model company. That stall is this post. It is not a count from other reviews, and it is not a stall on isolation alone.

The same day, a comment names a "tenant isolation test" and says "the strongest answer is evidence from a repeatable test, not a paragraph saying the agent cannot cross a boundary." Company and headcount are not stated.

What data a vendor can see is a different row. Whether a model company belongs on the vendor list is a different row. A log of who did what is a different row.

What reviewers accept

Name the mechanism only when it is true. Separate databases, a schema for each customer, or a customer id on each row with a check that refuses the wrong customer. Write only the one you can show. If your product calls that id a tenant id, you can use that word. Write it only when the check is real.

If customers share a cache, an embedding store, or a model, say so, and name what stops one customer's data from being returned to another. A shared store is not covered by the word isolated.

An agent that cannot read or change another customer's data is its own sentence. How the accounts are stored does not answer it. Write the agent sentence only when you can show the boundary.

If you have not chosen a mechanism, say you are still deciding. If you have not checked, say not yet. Do not write isolated.

A reviewer may create a user with the lowest role and try to open another customer's project. That is their check. If you have run it, write what happened and the date. If you have not, do not invent the test. This page does not run it.

An honest gap is a complete answer. The answer that fails is isolated, or a paragraph that says the agent cannot cross a boundary, when you cannot show the mechanism.

What not to write

Do not write isolated, logically separated, or tenant isolation with no mechanism behind it.

Do not answer who on your team can open this customer's account here. That row uses tenant for this customer's account.

Do not answer what data a vendor can see here. That is a different row.

Do not answer a log of who did what here. That is a different row.

Do not treat a shared cache, embedding store, or model as covered because the databases are separate. Name the shared store.

Do not say an agent cannot cross a boundary unless you can show the check. A paragraph is not the test.

Do not draw a diagram and send it as this answer. The mechanism is the sentence. This page does not draw a diagram.

Do not claim this page ran a tenant isolation test. It does not test the boundary.

Do not invent a mechanism, a test, or a deal that stalled.

Where this answer lives

Keep these sentences in the questionnaire answer you control.

The public page shows your company name, a short summary, and a contact email. Each row shows the company, what it does, the processing location, the agreement link, and the date you saved it.

You can mention a boundary in the purpose line you type. That line is text you write. The page does not test it.

There is no field for an isolation claim, a tenant boundary test, or a diagram. The page does not fill this row.

If the editor already knows a company, a suggestion can offer a location or a public agreement link, and only after you use it. That suggestion does not write an isolation claim.

If you want the longer notes

Who on your team can still open this customer's account is a different row. That guide uses tenant for this customer's account. What to write is in the access review guide.

What data each vendor can see is a different row from whether one customer can see another's. What to write is in the data access guide.

Naming a model company on the vendor list is a different row from how your product keeps one customer off another's data. What to check is in the AI provider guide.

Whether customer data trains a model, including a fine-tune and what happens when redaction misses, is a different row. What to write is in the customer data training guide.

A log of who did what is a different row from whether one customer can reach another's data. What to write is in the audit log guide.

The short packet for a questionnaire without SOC 2, including how customers stay separate, is in the security questionnaire guide.

What the agent is allowed to do is a different row from whether one customer's agent can reach another's data. What to write is in the agent permissions guide.