AI Security for Private Equity: Lessons From Three Penetration Tests
Venture capital and private equity firms are adopting AI assistants at a rapid pace. Deal teams use them to summarize data rooms, draft investment memos, screen targets, and pull insight from portfolio company reporting. The productivity gains are clear. The security risks get far less scrutiny.
We recently assessed several custom-built applications powered by large language models (LLMs) for numerous firms in this space. The findings were serious. Below are three examples, each drawn from a real engagement.
Example 1: An Exposed Development Environment With Hardcoded Admin Credentials
Within ten minutes of starting the engagement, we identified a development version of the client’s application directly accessible from the internet. The login page displayed a prefilled username, “admin,” alongside a masked password. A clear sign the credentials were hardcoded. One click on “login” granted full admin access.
After logging in, we found production data inside the development application. Teams often treat dev environments as low risk, but real data turns one into a production-grade target with weaker defenses. As an admin, we also modified the system prompt and directed the application to carry out malicious activity on our behalf.Â
By the end of the test, we had gained access to:
- DealCloud and all the data within itÂ
- SalesforceÂ
- M365Â
- Internal documents hosted in EgnyteÂ
- Metadata instance tokensÂ
- API keys and other credentialsÂ
A real bad actor with this level of access could have caused significant damage.
Example 2: Production Users With Too Much Power & Too Little Oversight
In another engagement, the application granted ordinary, non-administrative users a broad set of capabilities with few of the controls a security-conscious deployment requires. End users could connect arbitrary MCP servers, create custom skills, and select older legacy models. The system prompt lacked hardening, and no logging or alerting existed to flag malicious use.
For a bad actor, the consequences write themselves.
Combined, these gaps give an end user, or an attacker operating through a compromised user account, several independent paths to harm. A rogue MCP server or skill could exfiltrate data the application processes. Downgrading to a legacy model could weaken the application’s safety posture. A custom skill could plant malicious instructions that persist across sessions. With no LLM specific monitoring, none of it would trigger an alert and a true breach could take place with minimal insight.
This risk runs deep in private capital. Deal teams often share broad access to sensitive materials, and one phished analyst account can become a quiet channel for pulling deal materials out of the firm.
Example 3: A Sandbox That Could Be Talked Into Attacking its Own Network
A chatbot ran code inside an execution sandbox, an isolated environment built to contain it. That sandbox failed to hold its boundary. Through prompted interaction, we directed the bot to:
- Scan the network for other reachable hosts and identify running services outside the sandboxÂ
- Run a penetration test against its own environmentÂ
- Execute Python codeÂ
- Query the cloud metadata service and return key material usable for Azure authenticationÂ
- Access untrusted URIs directlyÂ
- Open a reverse shell back to our listening host, giving us remote command and control of the sandbox serverÂ
The core problem was that model-level guardrails were the only control standing between us and these actions. Guardrails add a useful layer, but they do not form a security boundary. Talk a model into cooperating, and few other obstacles stand in the way.
For a firm whose cloud tenant may also hold fund administration, investor reporting, and portfolio data, a sandbox that reaches the metadata service opens a direct route to broader compromise.
Key Takeaways for Building & Securing AI Applications
- Treat AI applications like any other internet-facing system. Follow basic security hygiene, including avoiding public development environments, eliminating hardcoded secrets, and keeping production data out of test systems. MFA and SSO should be standard.Â
- Do not rely on a model’s training to enforce security. If a prompt is the only thing preventing network scanning or credential theft, it is not a security control.Â
- Give users only the access they need. Custom skills, tool integrations, and model selection are powerful capabilities and should be approved decisions rather than default permissions.Â
- Hold third-party AI vendors to appropriate security standards. Many private capital firms purchase or commission these tools rather than build them internally, making security requirements and pre-release testing important components of the contract.Â
- Build visibility into AI activity. If you cannot see prompts, tool calls, and configuration changes, you cannot detect misuse. The ability to alert on anomalous activity already exists, so organizations should take advantage of it.Â
If your firm is deploying or evaluating AI-powered applications, test them before they reach production. An independent assessment puts your tools under realistic attack conditions and delivers clear, prioritized findings your deal, IT and compliance teams can act on.
Every finding above came from a real engagement, and every one was preventable with the right controls in place. Contact our cybersecurity team to scope a test built around how your firm actually uses AI.
