Private-Wealth AI Threat Model
A threat model asks four blunt questions: What are we protecting? Who could misuse it? Where does control change hands? How would we recover?
What threats should a family office test before using AI with private records?
A private-wealth AI threat model lists the records, people, systems, credentials, and relationships that need protection. It traces how information moves, where a person or system could misuse it, what signals reveal a problem, and how the office would contain and recover from the event.
What Belongs in the Threat Model?
Map financial records, entity structures, tax and legal material, personal correspondence, household operations, security information, and sensitive relationships. Include the derived data and operating layer: embeddings, prompts, answers, model settings, identities, access tokens, logs, backups, and administrator notes.
OWASP’s risk categories for large language model applications include prompt injection, sensitive information disclosure, supply-chain risk, improper output handling, excessive agency, and system prompt leakage. A family office should translate those categories into its own people, records, and decisions. The AI governance framework then assigns owners to the selected controls.
Which Controls Should the Office Test?
| Threat | Primary control | Verification |
|---|---|---|
| Shadow AI and disclosure | Approved tools, data rules, and staff examples | Attempt prohibited uploads; review tool inventory |
| Prompt injection | Treat retrieved content as untrusted; restrict tools | Seed hostile instructions in a permitted document |
| Excessive agency | Minimum permissions, approval, limits, revocable credentials | Attempt an action outside scope |
| Improper output handling | Validate output before email, databases, or code | Send malformed output to a safe test system |
| Administrator access | Named, approved, time-bound support access | Exercise access and verify revocation |
| Retention and copies | Rules for prompts, answers, indexes, backups, and logs | Delete a test record and trace copies |
| Provider outage or exit | Portable records, dependencies, and alternate workflow | Run a tabletop with the provider unavailable |
The test evidence matters as much as the written control. “Human approval” has little value if the reviewer cannot see the source, the proposed action, and the consequence.
Where Does Control Change Hands?
Mark the handoffs between the person and the interface, the interface and each data source, retrieval services and indexes, the control layer and model providers, an agent and its tools, and the environment and its administrators, backups, or monitoring providers.
For each line, record who signs in, what crosses, where it is stored, who can inspect it, and how access ends. Include successor access. A permission designed for today’s investment team may be wrong when an adviser leaves or responsibility passes to another generation.
A local model can still leak or misuse data
Local processing reduces some provider exposure. It does not correct broad internal permissions, compromised laptops, unsafe connections, weak backups, unreviewed software actions, or a missing incident plan. Apply the same analysis to the document system that feeds the model.
How Can You Test Readiness Before Production?
- Wrong person. Confirm one role cannot retrieve another role’s records.
- Poisoned source. Put hostile instructions in an approved test document.
- Wrong answer. Supply conflicting sources and require citations and uncertainty.
- Wrong action. Ask software to bypass approval or send data elsewhere.
- Provider unavailable. Preserve the records and continue the priority workflow.
Use synthetic records for destructive and adversarial tests. Record the expected result, actual result, owner, and remediation. Re-run the tests after a model, connector, permission, or operating process changes.
What Should the Incident Plan Contain?
Name the people who can stop the system, revoke credentials, isolate connections, preserve evidence, and contact providers or counsel. Define which records, indexes, prompts, answers, logs, and downstream actions the team must inspect. The plan should also identify the fallback process for the underlying office work.
Recovery ends with a verified change. Restore from a known source, confirm permissions, rerun the relevant tests, and document why the incident should not repeat. Avoid retaining every prompt or document indefinitely as a precaution. Excessive logs can create another sensitive archive. Keep the evidence needed for the stated review and retention purpose.
Common questions
What is the biggest AI risk for a family office?
It depends on the work. Disclosure, broad access, false answers, and unreviewed actions can each cause harm. Rank them against the office’s actual records and decisions.
Are embeddings sensitive data?
They can contain information derived from source records. Apply deliberate rules for access, storage, backup, export, and deletion.
Can audit logs create privacy risk?
Yes. Logs may contain prompts, answers, names, source references, and actions. Limit access and retention, and avoid collecting content the audit does not need.
Sources and further reading
Sovereign Layer develops private AI for family offices. Will Scott designed the approach around firsthand investment experience and the need to keep private records under client control. Comparisons explain fit by task; they are not independent product rankings.
Book a Private Demo
Describe the records, handoffs, and decisions in one workflow. Please do not send sensitive files through the website.
Book a Private Demo