The "models being untamed hackers" headlines are all over your feed, and the argument is mostly about intent. Intent is the least interesting part. What matters is that you are about to hand that same class of model direct access to your own infrastructure, and when it comes to automating your security it would be insane to let them make the final call on their actions. Until they stop making mistakes, you can't afford to let your agent hallucinate into deleting your data or changing your cloud infrastructure configurations.
One way around this is to mirror key parts of your infrastructure into a data lake and have the agent operate there, not touching your live infrastructure directly. That's how all SaaS security products operate: Palo Alto Networks, CrowdStrike, Wiz and the AI-native challengers. It's a valid path, but it comes with a price: cost, partial data, sync delay and, most importantly, you're bound to choose between loss of data sovereignty and huge operational overhead.
The classic defender-attacker asymmetry is real, and it's becoming more of a problem when the attackers have frontier models and coding agents at their disposal to find and automatically exploit any potential crack. Resources alone no longer compensate for this gap the way they used to: you need a sovereign agent with direct access to your infrastructure.
We've heard the same pattern from partners at some of the largest enterprises, who were given restricted early access to one of the frontier labs' top-tier models. Finally, they had access to a reasoning model more capable than the ones attackers have, but since they didn't have an agent they could trust with such sensitive access, they opted for copy-pasting code repositories in-prompt — pricey, code with no runtime around it, no sync and the overhead of a dedicated special-mission team siloed from the rest of the organization.
You should grant your agent least-privilege read-only access to your infrastructure. But that's not enough: server-side identity and access management in a large organization tends to drift. Agents will find creative ways to change their own boundaries if you give them the opportunity.
The approach we took to solve this gap while building our infrastructure security deep research agent, Cynative, is a two-sided architecture: a sandbox and an action-gate. The sandbox runs the model-authored code with no access to the outer world — no network, no filesystem, no host APIs, nothing but the tools we explicitly register. The action-gate authorizes every connector call against a read-only policy before a credential is ever attached, and fails closed. The agent is read-only by construction, not by an opt-in filter it could talk its way around.
This way, the sovereign agent has the flexibility of a coding agent to reason ephemerally on the live data it needs, while it cannot, by any means, change the live infrastructure or leak data out of it. The same principle runs through the rest of it — sessions the cloud provider itself keeps read-only, secrets redacted before they reach the model, a fail-closed audit log — but each of those is a post of its own.
The model still sees everything you point it at. So Cynative ships as a single binary that runs inside your own environment, against whatever model endpoint you choose — including the ones your cloud provider already runs for you. Point it at those and the infrastructure, the model and the agent all sit inside the same account: you're running security on your infrastructure from within your infrastructure.
If you're building your own security agent, the boundary holds when two things are true: the reasoning environment cannot reach anything you didn't explicitly hand it, and the allowed set is decided at design time, with no path for the agent to widen it while it runs. Get them wrong and the boundary becomes a suggestion the model is free to reinterpret the moment it decides the task requires it. Get them right and you can point the thing at production and go to sleep. We've built this as an open-source project so you can use it freely, to conduct deep research on your infrastructure or as a framework to build security agents of your own, leveraging this architecture and implementing your workflows and logic.
Code and docs available here: github.com/cynative/cynative