A login is not proof that client data stays separate.

Ask which client owns every piece of work

A tenant is the organization or account whose information must stay within an agreed boundary. Define that boundary before discussing the model. A person may belong to several clients, and a manager may have wider access than an operator within one client. Write down both account membership and allowed actions. A role called manager is incomplete unless it is clear which client the person manages.

AWS’s guidance distinguishes authentication and authorization from tenant isolation: signing in and having a role do not by themselves establish that another tenant’s resources are inaccessible. Use that distinction in a supplier review. Ask how a valid user is prevented from reading or changing a record owned by a different client, even when they know its identifier.

Follow the request beyond the chat window

Ask the builder to trace one question from the signed-in session through search, record retrieval, model context, and any action it invokes. The application should establish the allowed client context from trusted identity and membership information. A client name in a prompt or a selected account in the interface is a request to validate, not proof of permission.

Apply the boundary before private material reaches the model. Telling an assistant not to mention another client is too late if that client’s documents are already in its context. The same question applies to tool actions: show where the destination record and requested operation are checked independently of the model’s proposed arguments.

Test changing access, not only first login

Use two synthetic clients and at least two roles. Confirm that each allowed operation works, then repeat it with the wrong client or role. Include a copied record link, an attachment URL, a search result, a generated report, and an attempted write. Do not use real customer secrets to prove a boundary.

Now remove a user’s membership while a session is open and while a job is queued. Ask when the change takes effect, how existing sessions and caches are handled, and whether an already-issued download link remains usable until it expires. Record the actual behavior and any accepted exposure window. “We have roles” does not answer these lifecycle questions.

Test a user who legitimately serves two clients. Switching the active client must not carry a previous conversation, attachment selection, or draft destination into the next task without an explicit, authorized rule. In a hypothetical agency assistant, a summary prepared for client A must not appear in client B’s dashboard simply because the same operator opened both.

Treat exports, logs, and support tools as part of the product

A correctly filtered dashboard is only one surface. Ask who can open exported files, see execution logs, replay failed jobs, or inspect model traces. Those records may contain the same private inputs as the original task. Define recipients, retention, support access, and offboarding for them as well.

If an administrator can act across clients, document that capability rather than pretending it does not exist. Ask how that access is granted, limited, recorded, and removed. A supplier should be able to explain the operational exception and show who reviews it.

What DBAI’s SentiVox case study establishes

The published SentiVox case study describes five roles, route checks, company scoping in queries, and private media delivered through short-lived presigned links. Those are concrete architectural boundaries a buyer can ask about. The case study is not an independent security audit or proof that every possible cross-client path has been tested. Request evidence for the exact workflow and version being proposed.

Copy this access review brief

# AI system client-access review
Workflow and version under review:
Client boundary and membership source:
Roles and allowed read / write / export actions:
Trusted source of active client context:

## Trace the boundary
Search and source-document access checks:
Model context and conversation separation:
Tool action target and permission checks:
Cache, background job, and retry ownership:
Export recipients and download-link lifetime:
Logs, model traces, and support access:
Membership removal and offboarding behavior:

## Demonstrate with synthetic data
Client A / client B / test roles:
Allowed read and write:
Other-client record ID or copied link:
Other-client attachment and search snippet:
Account switch with prior conversation:
Removed membership during an active session:
Queued export after access changes:
Denied write leaves destination unchanged:
Expected result / observed result / evidence:

## Decision
Untested surfaces and limitations:
Accepted access-change delay, if any:
Owner and deadline for each gap:
Retest after permission or integration changes:
Proceed / narrow scope / repair before launch:

Use the demonstration to identify gaps and agree the next validation step. A checklist helps structure procurement; it does not replace a security review of the implementation. Keep evidence tied to the tested release and repeat affected checks when permissions, connectors, or background workflows change.