Opula

Post

Is it safe to connect your finances to an AI assistant?

Connecting your holdings to an AI assistant through an MCP connector means handing a hosted service your financial data. Here is the risk model, the questions to ask any connector, and exactly where Opula lands on each.

You can now connect your financial data to Claude or ChatGPT through an MCP connector and ask questions about your own money. The obvious next thought is the right one: that means handing a hosted service your holdings. It is a real ask, and "trust us" is not an answer.
This post is the risk model. What can actually go wrong, what to ask any finance connector before you add it, and where Opula lands on each. Some of the answers are uncomfortable, and those are the ones worth reading.

The three risks, separated

People collapse "is it safe" into one feeling. It is three different questions with three different answers.
1. Can another user see my data? A multi-tenant service holds many people's finances in one database. The failure mode is one tenant's query returning another tenant's rows. This is the risk you cannot inspect from outside, and it is the one that matters most.
2. Can the company see my data? Someone operates the service. What they can read, what they log, and what they would hand over are separate questions from tenant isolation.
3. Can it move my money? A connector that holds brokerage credentials can, in principle, act. One that holds none cannot, no matter what goes wrong.
They are independent. A connector can be excellent at one and poor at another.

What to ask any finance connector

Five questions. They work on us and on everyone else.
  1. Is every request authenticated as you, or does the server run as one shared identity?
  2. Is tenant isolation enforced by the database, or by application code remembering to add where user_id = ...?
  3. If a developer forgets a check, does the query return nothing, or everything?
  4. Does it hold credentials to any account you own?
  5. Can it place a trade, move money, or change an account setting?
Question 3 is the one most people skip and the one that decides the outcome. Every system has a bug eventually. What matters is which way it fails.

Where Opula lands

Every tool call is authenticated as you. Opula is a hosted MCP connector, not a script running on one machine. Each request carries a token that is verified before any tool runs, and the whole call executes inside a context scoped to your user id.
Isolation is enforced by Postgres, not by our code. Every table holding your data has a row-level security policy tying each row to your user id, applied to reads and writes alike. This is not our application filtering results after the fact. It is the database refusing to return rows that are not yours, underneath any query we could write.
A missing check fails closed. The database role our application uses cannot bypass row-level security. Your identity is read from the verified token. If that identity is ever absent, it evaluates to null, no row matches, and the query returns nothing. The failure mode of a bug in our code is an empty result, not someone else's portfolio. This is the single most important design decision in the product, and it is the reason we chose Postgres RLS over doing it in TypeScript.
We hold no credentials to anything you own. Opula never connects to a brokerage or a bank. There is no aggregator, no stored login, no read-only account link. You tell it what you hold, in conversation or by import. That is a real cost: you do more data entry than with a sync-based tool. It is also why the answer to "can it move my money" is not "we promise not to." It is that there is no path from Opula to any account of yours.
It cannot trade, and it will not advise. No orders, no transfers, no personalized investment advice. Opula computes diagnostics ("what is true about my money right now") and thought experiments ("what happens under assumptions you supply and we disclose"). What to do about the answer is yours, with your own advisor. Tax treatment we defer entirely to a local professional.
You bring no API keys. Earlier versions asked users to supply their own market-data and macro keys. That is gone. Market data is fetched from keyless sources, macro from a single server-side key we hold and never expose. There is no store of your credentials because there is nothing to store.

What we cannot promise

The honest part.
It is hosted. Your holdings sit in our Postgres, not on your laptop. Row-level security protects you from other tenants. It does not make the data disappear from a service we operate. If your requirement is that your financial data never leaves a machine you control, no hosted connector meets it, including this one. That is a legitimate requirement and you should act on it.
The assistant sees what it retrieves. When Claude or ChatGPT calls an Opula tool, the result enters your conversation with that assistant. What happens to it there is governed by Anthropic's or OpenAI's policy, not ours. Read the one that applies to you.
Correctness is not the same as safety, and we make no claim to be a financial institution. Opula holds no custody of assets and is not a broker, an advisor, or a bank.

The short version

The strongest security property Opula has is not a feature. It is an absence. It holds no credentials to any account you own, so the worst-case outcome of a total compromise is disclosure of a portfolio you typed in, not a transfer of anything. Everything else, the per-request auth, the database-enforced isolation, the fail-closed default, is there to make that disclosure hard.
Ask any connector you are considering the five questions above. If the answer to number 3 is "we're careful," keep looking.