Every software vendor serving private funds shipped an AI feature in the last eighteen months. Almost all of them shipped the same one: a chat box in the bottom-right corner of their product.
We shipped one of those too. It's genuinely useful, and it's not what this article is about.
This is about the opposite move — the one that took longer and matters more.
Instead of putting an AI inside our product, we made our product available to the AI you already use. Twenty-three read-only tools. Your own API key. Your own model choice. Your governance rules, enforced on our side.
The question your IC is already asking
"What's our AI strategy?"
The honest answer at most GPs in the $500M–$10B band is some version of: our administrator's platform added a chat box, and two people on the team pay for a consumer AI subscription out of their own pocket.
That second half is the interesting one. Your team is already using an AI client daily. What it can't do is see your fund data — so they paste it in. Screenshots of the cap table. Exported capital account statements. A pasted KPI grid.
That's not an AI strategy. That's an exfiltration channel with a subscription.
Your team isn't waiting for you to choose an AI tool. They chose one. The only open question is whether it reaches your data through a governed connection or through the clipboard.
What it looks like in practice
An operations lead opens their AI client — the same one they already use — and types:
"Compare TVPI and DPI across all my funds as of last quarter, and flag any fund where called capital is above 80% of commitments."
The client calls our tools. It pulls the fund list, the ratio set, and the commitment aggregates. It assembles the answer.
What it does not do is compute the ratios. Those come out of the platform, calculated by the same engine that produced the numbers in the last LP report — because a number that an LLM arrived at by arithmetic is a number you cannot defend in a diligence call.
The AI's job here is retrieval, framing, and synthesis. The fund's job is the math. That line is deliberate, and we don't cross it.
The three questions procurement will ask
Every one of these came up before we shipped. Each shaped the design.
"Can it change anything?"
No. Not "we've restricted it" — there is no write path. All 23 tools are read-only. The connection cannot create a capital call, edit a valuation, or delete a document, because no tool exists that does those things.
"Whose data does it see?"
Only what the authenticated user could already see in the product. Every query resolves through the same user and entity scoping the web interface uses. There's no service account, no elevated connector identity, no cross-tenant surface. If a user can't open a fund in the UI, the AI can't read it either.
"Who decides who gets it?"
Two levels, deliberately separated:
- The platform gate — whether your firm has MCP access at all. Commercial, controlled by us.
- Your gate — which roles inside your firm can connect, and which AI clients are permitted. Self-serve, controlled by your own admin, changeable without a support ticket.
That second gate includes an option most firms don't expect: you can extend access to the investor role. An LP asking their own AI client about their own capital account, scoped to exactly their own folio. Most firms will start with employees only — but the model supports it, and the scoping is the same code either way.
"Read-only" is a promise. "No write tool exists" is an architecture. Ask any vendor which of the two they're offering.
⚙️ Under the hood: no secrets to distribute
The part I'd want to know about if I were evaluating this.
Connecting doesn't involve a client ID or a client secret. The AI client registers itself dynamically — OAuth 2.0 Dynamic Client Registration, RFC 7591 — and authorises with PKCE, the flow designed for public clients that can't keep a secret.
This sounds like plumbing. It's actually the security property that matters most operationally.
The alternative — issuing each firm a client secret — means a credential exists that has to be transmitted, stored, rotated, and revoked when someone leaves. That credential is the thing that leaks. It leaks in a Slack message, a runbook, a screenshot in a support ticket.
With dynamic registration, there's no such artifact. A user authorises with their own login, gets a token scoped to themselves, and that token expires in 30 days with automatic refresh. When they leave, disabling their account ends their AI access at the same moment it ends their web access — no separate revocation step to forget.
And every tool call is logged. Not just the connection — each individual query, attributable to a user, available for audit.
| Chatbot inside the vendor's product | Fund data callable from your AI client | |
|---|---|---|
| Where the AI runs | Vendor's infrastructure, vendor's model | Your client, your model, your key |
| Model choice | Whatever the vendor picked | Yours — set a default model per entity |
| Who pays for inference | Bundled into the licence, opaque | Your API account, itemised |
| Scope of data | Whatever the vendor's chat is wired to | Exactly what that user can already see |
| Works alongside your other tools | No | Yes — same client, same conversation |
| Leaves an audit trail | Sometimes | Every tool call, per user |
Bring your own key — and your own model
The same principle runs through our LLM configuration. Each entity can supply its own Anthropic or OpenRouter API key, and set its own default model.
Three consequences, all commercial rather than technical:
Billing is yours and it's itemised. AI usage shows up on your API account, not buried in a per-seat licence with a margin on top. You can see what you're spending and on what.
Model choice is yours. When a better or cheaper model ships — and one will, within months — you switch. You don't wait for our release cycle, and you don't get switched without being told.
The data-residency conversation gets simpler. You're contracting with the model provider directly, under your own terms, rather than asking us to explain a sub-processor relationship in an LP's diligence questionnaire.
If your AI features run on your vendor's key, your AI cost, your model, and your data-processing terms are all decisions someone else makes for you.
📊 The impact
Before: a cross-fund question meant an export, a workbook, and an analyst's afternoon — or a screenshot pasted into a consumer AI tool with no governance at all.
After: the question is asked in the client the team already uses, against 23 read-only tools, scoped to the asker's own permissions, with every call logged and zero write paths exposed.
The measurable shift isn't time saved on any single query. It's this: the number of times fund data leaves your controlled environment to answer a question goes to zero — because the governed path is now easier than the clipboard.
What to take from this
- Assume your team is already using AI on your data. The useful question isn't whether to allow it. It's whether the path they're using is one you can audit.
- "Read-only" should mean no write tool exists. Ask any vendor to describe the write path they've disabled. If they can describe one, it's a configuration, not an architecture.
- Scoping must reuse the product's own permissions. A connector with its own service account and its own permission model is a second access-control system to keep in sync — and it will drift.
- Prefer dynamic registration over shared secrets. Any credential a human has to copy between systems is a credential that ends up somewhere it shouldn't.
- Don't let an LLM compute your numbers. Retrieval, comparison, and drafting: yes. Arithmetic that reaches an LP: no. Keep the calculation in the system that can show its work.
See it on your own structure
If you want to see what your own funds look like from inside your AI client — same permissions your team already has, nothing new granted — DM me and I'll set up a walkthrough on your structure.
Worth doing even if you don't take it further: it makes the governance conversation concrete in a way a policy document never does.
Question for the operators here: has your firm written down what your team is allowed to paste into an AI tool? Not what the policy should be — whether the policy exists. My sense is that most firms are one quarter behind their own staff on this.