Security
Before you connect AI to your research
Schuyler Fried
·
·
4 min read
At a glance
Test a real research workflow using a defined set of filings, internal notes, and models, with access limits enforced by the platform.
Decide separately whether AI may read information, prepare changes, update shared research, or distribute the result.
Revisit those permissions as new integrations are added, and test that unauthorized access and actions are blocked.
An analyst asks an AI platform to update a credit after earnings. To do that well, the platform may need the new filing, last quarter’s internal note, and the team’s financial model. The analyst probably wants it to find the relevant disclosures and prepare changes. They may not want it to overwrite the model or circulate a new recommendation.
“Update the credit” leaves all of that unstated.
This is where I would start when deciding how to connect AI to an investment firm’s systems. Useful research requires access to the team’s work. The firm should be able to provide that context while deciding separately what the platform can change and who it can send information to.
Give it enough context to do a real job
A trial using only public filings can test whether a platform extracts figures and answers questions accurately. It cannot fully test whether the platform can help maintain the firm’s coverage. That requires knowing which adjustments the analyst accepts, what the model assumes, and which questions remained open after the previous quarter.
For an earnings-update trial, I would start with a small coverage group and a defined set of materials: the relevant filings, selected internal notes, and copies of the models the team wants to update. That gives the platform something useful to work on without requiring access to the entire research repository.
The important detail is that these should be enforceable access limits. Selecting a folder in a prompt is not the same as limiting an integration to that folder. The vendor should demonstrate that the platform cannot retrieve material outside the agreed scope.
With that foundation, the analyst can supply the context needed for a meaningful test. Otherwise, the firm risks evaluating a research assistant while withholding the information it needs to assist.
Separate preparing the work from committing it
Once the platform has read the materials, the next question is what it may do with them.
Consider a model update. Populating a new quarter’s reported figures and changing the analyst’s forward assumptions are different decisions. The team might eventually automate the former while continuing to review the latter. At the start, both can be prepared in a working copy, with the existing model preserved.
The review should show which cells changed, where the figures came from, and whether a change reflects a new disclosure or an analytical assumption. An approval button is of little use if the analyst has to reconstruct that information before clicking it.
Saving and distributing the research deserve the same attention. A draft should have an obvious destination and status. Permission to prepare it should not include permission to replace the shared credit note or email a distribution list. Those actions need their own rules, including who can authorize them.
This lets a team automate the preparation it finds valuable without surrendering control over the research other people rely on.
Expand access when the next task requires it
A successful earnings workflow may lead the team to request another integration: a document room, an internal research archive, or an email digest. Each addition changes what the platform can see or do. The original approval should not be treated as covering all of them.
The review can be specific. Which additional materials are needed? Will the platform only read them, or write back? Who will receive the output? Can the firm disable the new connection without interrupting the work already approved?
Before expanding, I would also test the limits already agreed: attempt to retrieve an out-of-scope document, make an unapproved edit, and send an output to an unauthorized destination. Use synthetic material. Ask the vendor to show what is blocked and what the administrator can see afterward.
A firm should finish the trial with a precise description of the workflow it is willing to run: which sources it uses, which changes it prepares, who reviews them, and where approved work goes. That makes the next rollout decision manageable. The team can grant more access for a specific purpose, with a clear understanding of what it is authorizing.

Schuyler leads product and engineering at Passu. He was previously head of engineering at AI real estate firm Zuma, backed by Andreesen Horowitz, and was a quantum computing scientist at Amazon and Rigetti Computing.
