Ask the vendor to trace one repository read and one finding read from a named user to the stored object, then show a controlled cross-customer denial at each independent boundary. A tenant ID in a request, an encrypted database, or a reassuring architecture diagram is not enough. The review should cover human and machine entry points, the service that owns the data, its storage credentials, and routes around the normal API such as exports, jobs, support and recovery. If the product is still being built, record those controls as design claims and leave runtime effectiveness unverified.
The answer changes with architecture. Separate databases can reduce some shared-table mistakes but still leave a shared worker, object store, log stream or support role able to mix customer data. A shared table can enforce strong partition limits if its application checks and cloud credentials are correct. Neither design makes contamination impossible. Your buying decision needs a map of where separation is enforced, a demonstration of denied paths, and a list of privileged exceptions.
Draw the route that private content actually takes
Start with one asset, such as a private repository and its vulnerability report. Follow its data through Git connection, source acquisition, processing, findings storage, search, exports, notifications, backups and deletion. Mark every point where a request selects an account or repository. Ask what makes that selection authoritative: a current membership check, a service-owned parent record, a scoped cloud credential, or merely a value supplied by the browser.
OWASP advises denying by default and checking permission on every request. Its authorization patterns guidance places an enforcement point close to the protected resource so it can check the object, action and tenant. A gateway check is useful, but it cannot by itself prove that a downstream worker, export service or direct object URL follows the same decision.
For each arrow in the vendor's diagram, write down five facts: the actor, the credential used, the selected tenant and resource, the data that can be returned, and the evidence of denial when the selection is wrong. Separate logical limits, such as repository entitlement, from cloud limits, such as an IAM condition on a database partition. Also ask which administrators can bypass either one for backup, incident response or repair. Those exceptional paths may be necessary; they need narrow ownership and a reviewable record.
Illustrative case: two customers, one shared regional table
Illustrative case; the companies, IDs and behavior below are invented. Northstar and Cedar each connect one private GitHub repository to a hypothetical scanner. The SaaS stores report sections in a shared regional DynamoDB table. Northstar analyst N-7 may read finding F-12 in Northstar's billing repository. Cedar analyst C-4 may read only Cedar's repository and findings. A background worker writes source-free finding summaries after a scan.
The expected path for N-7 is: signed-in identity → current Northstar membership → permitted action and repository → finding service checks F-12's stored repository and tenant parents → purpose-limited database credential → F-12's permitted section. Changing tenant_id, repository ID or finding ID in a request must not turn N-7 into C-4. A queued worker must not use a broad credential and rely on the tenant ID in its job message. A CSV export or report download must apply the same membership and object checks as the detail page. A cached summary and a search count are outputs too.
If the table uses tenant-prefixed partition keys, AWS documents dynamodb:LeadingKeys as an IAM condition on the partition key and requires the ForAllValues modifier for it (DynamoDB condition keys). Ask to see the actual key shapes and policy for the actions used, including batch and query paths. Session tags can be passed into AWS temporary credentials and used in policy conditions (AWS STS session tags). A tag is only as trustworthy as the service allowed to set it: “tenant from job payload” is not an independent boundary. Indexes, streams, object stores and administrative restores need separate review. Do not assume a table policy protects a different service merely because both store the same tenant ID.
Use a question-and-evidence sheet
Copy this into the vendor review. Request a diagram or artifact, then watch the path in a disposable environment with customer-approved synthetic records. Record design described, configuration observed, operation observed and unknown separately.
| Question to ask | Evidence to request | Decision if evidence is missing |
|---|---|---|
| How is the account selected and current membership established? | Identity binding, server-side membership source, revocation rule and a denied request using another account ID | Do not treat a URL, token claim or email domain as proof of membership |
| Which service verifies the repository and finding belong to that account? | Object-parent lookup and a wrong-parent read demonstration | Keep object-level isolation unverified |
| What does the runtime credential permit? | Redacted role policy, trust policy, session-tag issuer and allowed partition/action examples | Record application enforcement without claiming a second independent storage boundary |
| Can search, counts, exports, reports or notifications disclose foreign content? | Inventory of delivery paths and actual denied outputs | Limit the conclusion to the demonstrated route |
| How are workers, retries and schedules bound to one account? | Job identity, reauthorization point and a revoked-job outcome | Do not extrapolate an interactive denial to asynchronous work |
| Who can reach backups, logs or raw objects? | Separate administrative roles, approval and audit evidence | Record privileged exceptions and their owners |
| What happens after membership or repository access is revoked? | Timing and behavior for direct read, open session, queued job and download link | Mark future-access fencing unknown; previously delivered data cannot be recalled |
Encryption deserves its own row in the procurement packet, but do not substitute it for any row above. AWS says DynamoDB encrypts table data, indexes, streams and backups at rest using AWS KMS keys (DynamoDB preventive security guidance). That addresses storage protection. It does not tell you which application principal can ask DynamoDB for plaintext, or whether a vendor operator can access the decryption path. A claim that server-managed encryption makes the vendor unable to read reports requires different evidence.
A demonstration can pass at the API and fail underneath it
The CISO asks for a two-tenant exercise with synthetic records. The following is a fictional evidence packet, not a report of checks performed against any product. Northstar's user may read its finding F-12; Cedar's F-88 is forbidden.
| Probe and governing identity | Fictional result | What the buyer can conclude |
|---|---|---|
| Northstar user reads F-12 through detail API | Allowed, expected section only | The useful positive path works in this environment. |
| Same user requests Cedar F-88 | API denies before returning content | Application object check demonstrated for detail. |
| Authorized isolation probe uses the actual Northstar-scoped database session to request Cedar's synthetic key | Storage read allowed because session policy covers the whole table | Independent storage boundary fails despite the API denial. |
| Same user searches a Cedar-only marker | No rows, but total count is 1 | Search leaks existence/count information; “empty results” is not complete denial. |
| Same user requests a report export | Cached export contains Cedar's synthetic heading | Export cache is a distinct delivery failure, not cleared by detail checks. |
| Revoked Northstar member downloads an earlier link | Evidence unavailable | Future delivery after revocation remains unknown. |
This example evaluates a vendor that specifically promises tenant-scoped database credentials. An application-mediated design may deliberately use a shared service role; assess its stated trust model and compromise impact rather than automatically calling the architecture a failed IAM isolation feature. If the vendor promises a separate storage boundary, the supplied session must enforce it.
The storage probe belongs in a controlled vendor environment with approved synthetic data and the actual scoped session under review. The buyer should not receive production credentials or bypass controls on real customer records. Its purpose is to distinguish two independent layers: an API can deny correctly while a compromised workload credential still crosses the tenant boundary.
The vendor first responds by showing that DynamoDB encryption is enabled. That does not repair the session policy. It then shows a policy using a tenant tag, but the issuer accepts that tag from an unvalidated job payload. The reviewer keeps the credential boundary open: a correct condition evaluated against an attacker-selected tenant is not an independently bound tenant decision. The job issuer must derive the permitted tenant and purpose from authoritative state and limit who can set the tags.
Recheck the repair at the layer that failed
In the fictional follow-up, the issuer binds the grant to the stored job/account relationship and the runtime permission restricts the supported action/key combinations. The vendor supplies new policy and release identities, then demonstrates the foreign-key request denied using the new session. A sample success on Northstar's allowed key confirms the policy is usable. AWS's DynamoDB condition guidance and STS tag documentation explain mechanisms; the packet must still establish the application's actual key shapes and trusted issuer.
That closes the demonstrated storage defect. It does not close the count leak or cached export. Search needs an authorized result set before computing visible aggregates. The export needs both correctly scoped content generation and an access decision at delivery; merely removing Cedar's heading from one cached file is not a durable fix. An authorized follow-up must generate a new mixed-tenant fixture, inspect its content and challenge retrieval as the wrong tenant.
The CISO's decision is “continue synthetic pilot; hold private-source expansion until search, export and revocation evidence is complete.” It names a passed detail check, a repaired database boundary and three delivery obligations requiring evidence. This is more informative than averaging green and red cells into an isolation score.
Finally, preserve the administrative exceptions. A backup restore or emergency support role may intentionally have broader access under separate authority. Record that role, permitted purpose, approval and audit evidence. A successful ordinary tenant-denial exercise cannot establish that privileged staff have no content access, and a necessary recovery role does not excuse a broad ordinary task credential.
Translate the failed layer into an acceptance condition
Northstar's next private-source decision should name the outstanding paths individually. Search must compute visible counts from an authorized population, export must bind generated content and delivery to the permitted reader, and revocation must have a stated timing rule. The vendor can demonstrate these with synthetic markers and identities under the revised configuration. A second detail-page denial would add little to those questions.
Retain the distinction between an architectural promise and an observed operation. The scoped storage-session repair addresses the vendor's claimed independent layer; the application checks still have their own responsibilities. If the vendor changes that architecture, evaluate the new trust model explicitly instead of keeping the old assurance wording.
The buyer's record can then state which boundaries were observed, which depend on configuration or contractual evidence, and which privileged exceptions remain. That is a usable acceptance decision even though no finite exercise proves every future request will be isolated.
Make a bounded decision
A practical review can end in three states: acceptable for the proposed data and scope, acceptable only with a narrower pilot or contractual/control change, or not yet evidenced. Avoid turning one successful demonstration into a claim of zero tenant-contamination risk. List the residual privileged routes, especially support and backups, alongside the ordinary tenant-denial evidence. If the review is for a product that has no deployed environment yet, the honest outcome is a design assessment and a list of demonstrations required before private source is connected.
Next action: ask the vendor for one marked data-flow diagram and run the two-tenant sheet against one finding read and one export. Then use the support-access review for the privileged exception and the least-privilege Git permissions guide for the repository entry point.