Security, isolation and residency

Data is not pooled across tenants. A partner's records, mandates and evidence stay within that partner's tenant, and where required each of the partner's own clients is isolated inside it.

Hosting jurisdiction can be selected per tenant where local rules or client contracts require it. Residency requirements should be raised in discovery, because they shape the deployment.

Role-based access covers operating teams, risk, compliance, external auditors and, where relevant, the partner's own clients. Single sign-on runs against your identity provider so joiners and leavers are handled by your existing process.

Every claim carries a source and a tier. Every decision carries the data behind it, the reasoning, the people and the approvals. Retention rules are configured per tenant so the record lives as long as your obligations require.

Most partner procurement teams send the same instrument: a control questionnaire, a data flow diagram request, a sub-processor list and a set of contractual commitments on breach notification and deletion. We answer each on the basis of what is implemented, and we mark anything that is a roadmap item as a roadmap item rather than folding it into a yes.

The three questions that decide most reviews are where the data sits, who inside the vendor can reach it, and what happens to it when the contract ends. Residency is selected per tenant. Internal access is role based and logged. Deletion and retention are configured per tenant, so a partner whose own client contracts require a defined destruction window can hold the layer to that window rather than to a generic default.

Where a partner connects its own assistants or agents through MCP, those agents operate under scoped tenant permissions rather than a shared credential, and every action they take is recorded with its trigger in the same provenance chain as a human action. That matters in a review because an agent that can read investor records is, from a controls perspective, another principal with access, and it should be auditable on the same terms.

Reuben AI is not SOC 2 certified, is not registered with any securities regulator, and is not a licensed administrator, trustee, custodian or registry. We answer security questionnaires on the basis of what is actually in place rather than on certifications we do not hold.