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.

23read-only tools exposed
0write operations
30day access-token lifetime, auto-refreshing, revocable by…

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.

Fund dataCapHive MCPAI clientOps leadFund dataCapHive MCPAI clientOps lead"Compare TVPI across my funds"call tools (OAuth token)resolve user + entity scoperead-only queryonly this user's fundsresults (call logged)answer, numbers from platform

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:

  1. The platform gate — whether your firm has MCP access at all. Commercial, controlled by us.
  2. 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 productFund data callable from your AI client
Where the AI runsVendor's infrastructure, vendor's modelYour client, your model, your key
Model choiceWhatever the vendor pickedYours — set a default model per entity
Who pays for inferenceBundled into the licence, opaqueYour API account, itemised
Scope of dataWhatever the vendor's chat is wired toExactly what that user can already see
Works alongside your other toolsNoYes — same client, same conversation
Leaves an audit trailSometimesEvery 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

  1. 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.
  2. "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.
  3. 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.
  4. 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.
  5. 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.