Separate firm database
Your firm has a separate database.
Security
Built to limit how far
a breach can reach.
Your firm is the only firm in its database. Studio tools use that foundation, keeping your client records separate from other practices’ records.
01 / Your firm’s database
What happens if an attacker
gets into one database?
A shared database may contain records from many firms. With a separate database for each firm, that same database access reaches a different set of records.
The same incident. A different reach.One database compromised.An attacker gains access to the records in one database.
Shared databaseSeveral firms inside
Records within the compromised database
Several firms inside
the same boundary.
Database access gained
One shared database
Firm AClient records
Firm BClient records
Firm CClient records
One database. Multiple firms at risk.The compromised database contains records from more than one practice.
AdvisorCRM StudioEach firm has
Each firm has
its own boundary.
Database access gained
Firm A’s database
Firm A’s records at riskOutside this database
Firm BSeparate database
Firm CSeparate database
One database. One firm’s records.That database access does not, by itself, grant access to another firm’s database.
This illustrates access to one database, not a broader compromise of shared administration or infrastructure. The limits are explained below.
The same separation as you add tools
Your Studio tools use your firm’s information in AdvisorCRM. Adding a tool does not require mixing your client records with another practice’s records. Free and paid practices use the same database-separation model.
02 / What reaches the model
Tools limit what
the model receives.
Studio agents use tools to work with your firm’s information. A tool performs a defined task against your firm’s database and returns the information needed for that step. Sensitive identifiers, such as Social Security numbers, stay behind the tool boundary and are kept out of the model’s input.
The model processes the information returned to it. The protection is in controlling what is returned: a task-specific result or summary, rather than handing over the client’s complete record.
The Northstar example: how information reaches the model
Suggest a goal helps draft the client’s planning priority using the selected client’s records.
- 01
Your request
You select the client and ask the tool to suggest a planning goal.
- 02
The tool’s work
The tool accesses the authorized records and returns relevant planning context. Sensitive identifiers such as Social Security numbers are excluded from model input.
- 03
The model’s draft
Using that context, the model proposes wording for the planning priority.
- 04
Your decision
You review the draft, edit it if needed, and choose whether to save it. The report uses the saved wording.
Planning context in the example
“Wants to explore smaller future required distributions. Concerned about paying too much tax during conversion years.”
Proposed planning goal
“Explore ways to reduce future required distributions while keeping the near-term tax cost manageable.”
The suggested wording is a draft for the user to evaluate. It is not automatically treated as a statement the client made.
See the Roth tool take shape inside Studio03 / Model processing
Where the models run.
Studio uses models through Amazon Bedrock, AWS’s managed model service. Model processing takes place within AWS, rather than through a direct request to the model provider’s separately hosted API.
Database separation, tool-controlled access and model processing protect different parts of the information path.
Controlled tool results
Tools limit the information returned to the model.
Model processing in AWS
Bedrock provides the environment in which the model processes that information.
Using Bedrock does not mean every firm has its own dedicated model instance. Model processing and database separation are distinct parts of the architecture.
04 / Human responsibility
Approve the application.
Review the work you use.
Your team reviews and approves the application before launch. That approval authorizes the application for use by your team.
Once it is live, the person using the application is responsible for reviewing each report they produce. Launch approval does not mean Studio or your firm must separately approve every subsequent report.
At launch
The application is approved for use.
The designated reviewers approve the application version—its functionality, calculation rules, output format and workflow.
Elliot MarloweApplication ownerNaomi CalderRequired compliance reviewer
Both launch decisions are required in this Roth example. Reviewer selection during setup is not approval.
In everyday use
The user reviews each report.
The person using the approved application reviews the inputs, assumptions and resulting report before using it with a client.
The report does not return to the application’s launch reviewers each time it is created.
05 / For a closer security review
Where database
separation stops.
A separate database is not necessarily a separate physical server. Administration and underlying infrastructure can still be shared; a compromise there could affect more than one firm.
Database separation is one protection alongside access controls, secure configuration, monitoring, and incident response.
Questions worth asking any provider
“Multi-tenant” means a service has multiple customers. It does not tell you how their information is separated.
Ask what access to one database would expose, which administrative permissions span firms, and how those boundaries are tested. Shared systems can also enforce strong separation.
For compliance teams and technical consultants
Discuss your requirements with us before introducing Studio to your practice. Ask for the available documentation and walk through the information path in a working example.
- What information can a tool access, and what does it return to the model?
- How are sensitive identifiers excluded from model input?
- Which permissions are limited to one firm, and which administrative permissions span firms?
- Which models and AWS regions are used, and what retention and logging settings apply?
- What records are available to explain a tool’s actions and the application’s launch approval?
- Who reviews reports after launch, and does the firm require an additional approval step?
The Roth example on Inside Studio illustrates the agent roles, tool-mediated steps and review points behind the work. Use it as a starting point for a closer technical discussion.
See how Studio carries out the work