One detail in SemiAnalysis’s research on neocloud security stayed with me. A customer’s monitoring dashboard appeared to show only their own environment. Underneath it, the credentials could retrieve metrics belonging to every customer.
The screen the customer was looking at suggested a boundary that the system hadn’t actually enforced. That’s an infrastructure security problem.
I come to this as a founder who built an AI infrastructure company that was acquired by a security company, and now as an investor working across Tel Aviv and San Francisco. Security infrastructure for AI sits directly at that intersection. It’s an area I want to help shape through the investing work I’m building.
The systems that determine what a workload can reach, what an agent is authorized to do, and what happens when something goes wrong are fundamental to making AI useful in production. I believe there are meaningful companies to build around those responsibilities.
The interesting question is where those responsibilities need a new product, who will pay for it, and why a startup can serve them well.
SemiAnalysis gives us somewhere concrete to start.
Their researchers describe finding outdated software, exposed management interfaces, and failures to separate customers sharing infrastructure. In one environment, they demonstrated that a compromise could cross from one customer’s environment into another, using two tenants they controlled. Several weaknesses combined into a much more consequential failure. They also describe working with providers on fixes before publication. These are reported findings from their testing, rather than evidence that every neocloud has the same problems. SemiAnalysis’s research
What I find revealing is how familiar many of the ingredients are. We already know that software needs patching and credentials should have limited permissions. Yet knowing the rule leaves a considerable amount of engineering between the rule and a system that follows it reliably.
Someone has to know which machines are affected. Someone has to deploy the update without disrupting a customer’s workload. Someone has to verify that a replacement machine, a network change, or a new monitoring integration hasn’t reopened the same path.
That repeated work is where I start looking for an infrastructure business.
There is a useful earlier example in research my friends at Wiz conducted with Hugging Face. In 2024, researchers showed how a malicious model could execute code and expose weaknesses in shared inference infrastructure, creating the possibility of access across customers. Hugging Face worked with them on mitigations. This was a research disclosure, not a report of an observed criminal breach. Wiz’s research
A service that accepts models from users has to account for the possibility that loading a model also means executing untrusted code. That possibility belongs in the design of the service, including the permissions and isolation around the workload.
This is part of what makes the problem interesting to me. Supporting what customers want to do can introduce the very behavior the infrastructure must contain. A successful product has to preserve that usefulness while making the limits dependable.
The same question appears higher in the stack, when an agent receives access to a person’s tools.
In May 2025, Invariant Labs demonstrated an attack in which a malicious issue in a public GitHub repository redirected an agent into retrieving information from private repositories and exposing it in a public pull request. The setup gave the agent access to both public and private repositories; permissive tool approvals allowed the sequence to proceed. The researchers explicitly located the problem at the agent-system level, rather than in a defect in the GitHub MCP server’s code. Invariant Labs’ demonstration
The distinction matters. A tool can work correctly while participating in an action the user never intended. Permission to read one resource and permission to write another can combine into permission to move information between them, unless something enforces the difference.
A shared GPU cluster and an agent connected to GitHub require different engineering. I wouldn’t assume one product should secure both. But I see a common requirement: the system needs an enforceable account of what is allowed to cross each boundary.
That is what I mean by security infrastructure. Software that makes those limits part of how work executes, with evidence that they continue to hold as the environment changes.
I see several places where that could become a valuable business.
At the compute layer, I’m interested in products that help operators maintain customer isolation through the full life of a workload. Provisioning, network configuration, credentials, firmware, and machine reuse all matter. A product could begin with one painful responsibility, such as verifying that a machine is ready to move between customers, and expand as the operator trusts it with more of the process.
At the agent layer, I’m interested in authorization that fits the task being performed. An agent investigating a public bug report may need a much smaller set of permissions than the person who launched it. Those permissions may need to expire when the task ends. Certain transfers or consequential actions may need a separate decision before execution. The product challenge is making that practical without asking the user to supervise every step.
Across both, I’m interested in continuous verification. A security review describes an environment at a moment in time. Production keeps changing. There could be considerable value in a system that tests whether an important boundary still holds after a deployment, explains what changed, and helps the responsible team correct it.
These are starting points for company formation. Each still needs a buyer, an integration path, and a reason to become a product customers rely on.
The strongest objection is that much of this should already be handled by cloud providers, identity systems, and existing security vendors. I agree that they will address substantial parts of it. Some apparent startup opportunities will turn out to be missing features. Some customers will prefer to build the controls themselves.
So a convincing company needs a specific answer to why it should exist independently. Perhaps it can enforce a policy across providers that each see only their own environment. Perhaps it understands a workflow well enough to make a difficult control usable. Perhaps it can take responsibility for a recurring operational task that customers currently struggle to perform consistently.
I’d want to see that answer in customer behavior: an operator integrating it into provisioning, a developer depending on it to run an agent, or a security team using its evidence to approve a deployment. The willingness to put a product into a critical workflow tells us something that enthusiasm about the category cannot.
My conviction also doesn’t require settling how quickly AI is increasing the rate of cyberattacks. That is an important empirical question. The opportunity I’m describing has a more immediate basis: useful AI systems need access to compute, data, and tools, and that access has to be governed well enough for people to trust them with consequential work.
For me, that connects security directly to adoption. A team that can contain failures and explain what its agents are allowed to do has a stronger basis for putting them to work.
This is a direction I want to help advance. Security infrastructure belongs in the conversation about what enables AI, alongside the systems that make it faster, cheaper, and more reliable.
I’m particularly interested in founders who can name a boundary that repeatedly fails, identify the person responsible for it, and build something that makes that person’s work meaningfully easier. There is room for ambition here, beginning with a very precise understanding of what needs to hold.