OpenAI recently shared an important lesson from securing its frontier AI environment: internet access introduces significant risks for autonomous AI agents, and restricting that access needs to be a fundamental part of their security architecture.
AI agent security in a SOC starts with the environment the agents run in, not only with what they are allowed to do. The five decisions below cover that environment: no direct internet access, isolated cloud sandboxes instead of endpoints, disposable agents, audited reasoning alongside actions, and governance layered on top.
I’m speaking with more and more security practitioners who are using coding agents on their local machines to perform day-to-day security work. While these tools can be incredibly powerful, running agents with access to sensitive enterprise data, security systems, and the open internet creates significant and often underestimated risks.
Over the past two years, we’ve been building and operating autonomous agents for security operations. Our experience has led us to make five deliberate architectural decisions, starting with one that aligns closely with OpenAI’s recent findings: our agents run in isolated cloud sandboxes with no direct internet access.
Key Insights: What You Need to Know About AI Agent Security in the SOC
- AI agent security begins with architecture. Identity, scoped permissions, policy enforcement and approval workflows matter, but a properly authorized agent can still make a wrong decision. Conifers sets execution boundaries first and layers governance on top, so the question becomes what an agent can do when something goes wrong.
- No direct internet access, by design. Agents that handle sensitive enterprise information and critical security systems gain unnecessary exposure from unrestricted connectivity, including potential paths for sensitive data to leave the environment. They get information and capabilities through controlled integrations rather than arbitrary external connections.
- Agent execution is separated from the analyst’s laptop. Agents run in isolated cloud sandboxes under a centralized control plane and don’t inherit an analyst’s local credentials, endpoint privileges or network access. That lets Conifers enforce execution boundaries, manage access to enterprise systems and audit activity from one central location.
- Disposable agents limit persistent access. Most security tasks don’t need a persistent agent. Wherever possible, Conifers creates an agent for a task, gives it the context and capabilities it needs, and terminates it when the work is done. Agents should last as long as their task, not indefinitely by default.
- Audit the reasoning, not only the actions. Conifers has invested in detailed reasoning and execution traces that show how an agent reached a decision, beyond the final result. Those traces support accountability and performance improvement: finding mistakes, validating investigation quality, and improving model selection, efficiency and cost.
- AI agent security across an enterprise is a different problem from securing one coding agent on a laptop. Relying on autonomous agents for enterprise security operations requires a different level of engineering discipline. OpenAI’s findings are a reminder that the environment matters as much as the model’s capabilities.
Here are the five principles that have shaped our approach to running agents in production.
1. No Direct Internet Access. By Design.
This was one of our most important decisions.
Security operations agents work with sensitive enterprise information and interact with critical security systems. Giving them unrestricted internet connectivity introduces unnecessary exposure, including potential paths for sensitive data to leave the environment.
We designed our agents to operate without direct internet access. They receive the information and capabilities they need through controlled integrations, rather than establishing arbitrary external connections.
If an agent doesn’t need internet access to perform its job, why give it that capability?
2. Run Agents in Isolated Cloud Sandboxes, Not on Endpoints
We made a deliberate choice to separate agent execution from individual employees and their machines.
Our agents run in isolated cloud sandboxes under a centralized control plane. They don’t inherit an analyst’s local credentials, endpoint privileges, or network access.
This allows us to consistently enforce execution boundaries, manage access to enterprise systems, and audit activity from a central location.
For production security operations, we believe this is fundamentally different from running a coding agent on an employee’s laptop.
3. Make Agents Disposable Whenever Possible
One of the lessons we’ve learned from operating agents at scale is that most security tasks don’t require a persistent agent.
We create agents for specific tasks, provide the necessary context and capabilities, and terminate them when their work is complete.
This reduces persistent access, limits accumulated execution state, and makes it easier to operate large numbers of agents independently.
Agents should exist for as long as their task requires, not indefinitely by default.
4. Audit the Reasoning, Not Just the Actions
Traditional audit logs tell you what happened. With autonomous agents, that’s only part of the picture.
We need to understand what information an agent considered, how it reached a decision, which tools it used, and what actions followed.
We’ve invested heavily in detailed reasoning and execution traces, giving us visibility into the decision process rather than just the final result.
This matters for security and accountability, but also for performance. It helps us identify mistakes, validate investigation quality, optimize model selection, and continuously improve efficiency and cost.
If you can’t explain how an agent reached a security decision, you shouldn’t blindly trust the outcome.
5. Governance Is Essential, but It Isn’t Enough
Identity, scoped permissions, policy enforcement, and approval workflows are all important. We’ve built these capabilities into our platform.
But even a properly authorized agent can make a wrong decision. Governance controls alone don’t eliminate the risks created by an overly permissive execution environment.
That’s why we start with architectural boundaries: isolated execution, no direct internet access, limited access to enterprise systems, and disposable agents wherever possible.
We then layer identity, governance, and policy enforcement on top.
The objective isn’t simply to define what agents are allowed to do. It’s to limit what they can actually do if something goes wrong.
From Experimentation to Production Security Operations
Coding agents are powerful tools, and I expect security practitioners will continue finding valuable ways to use them.
But there’s an important distinction between using an agent to improve individual productivity and relying on autonomous agents to perform security operations across an enterprise.
The latter requires a different level of engineering discipline.
OpenAI’s findings are a timely reminder that the environment in which AI operates matters as much as the capabilities of the model itself.
Our experience building an agentic SOC has reinforced that lesson. The most important decisions aren’t always about making agents more capable. Sometimes they’re about deliberately limiting what agents can access, where they can run, and how they operate.
That’s how we’ve approached production security operations, and I believe those same principles will become increasingly important as enterprises move more autonomous agents into production.
See How Conifers Runs Agents in Production
The foundation of AI agent security is the environment in which agents run and the resources they can access. Book a demo to see how Conifers runs its security operations agents in production, or read how Conifers works with enterprise security teams.
Frequently Asked Questions
What Is AI agent security in a SOC?
At Conifers, AI agent security in a SOC means limiting what autonomous agents can access, where they run and how they operate before deciding what they are allowed to do. In Conifers’ approach, best practices for AI agent security include isolated execution, no direct internet access, limited access to enterprise systems and disposable agents, with identity, governance and policy enforcement layered on top.
Why should security operations agents have no direct internet access?
Security operations agents should have no direct internet access because they work with sensitive enterprise information and critical security systems. Unrestricted connectivity adds exposure, including potential paths for sensitive data to leave the environment. Agents can receive the information and capabilities they need through controlled integrations instead, which is how Conifers designed its own agents.
Why run AI agents in isolated cloud sandboxes instead of on endpoints?
Running AI agents in isolated cloud sandboxes separates agent execution from individual employees and their machines. Inside those sandboxes, under a centralized control plane, the agents don’t inherit an analyst’s local credentials, endpoint privileges or network access. Execution boundaries can then be enforced, access to enterprise systems managed, and activity audited from one place. For production security operations, that is a fundamentally different setup from running a coding agent on an employee’s laptop.
What are disposable AI agents and why do they matter for security?
Disposable AI agents are created for a specific task, given the context and capabilities that task needs, and terminated when the work is complete. Most security tasks don’t need a persistent agent. Disposability reduces persistent access, limits accumulated execution state and makes it easier to operate large numbers of agents independently.
Why does auditing an AI agent’s reasoning matter?
Auditing an AI agent’s reasoning matters because it shows what information the agent considered, how it reached a decision, which tools it used and what actions followed. Traditional audit logs only show what happened. Reasoning and execution traces support accountability, and they also help find mistakes, validate investigation quality and improve model selection, efficiency and cost. If a security decision can’t be explained, it shouldn’t be trusted blindly.
Is AI agent governance enough to secure autonomous agents?
AI agent governance is essential to securing AI agents, but it is not enough on its own. Identity, scoped permissions, policy enforcement and approval workflows all matter, and even a properly authorized agent can make a wrong decision. Governance controls alone don’t eliminate the risks of an overly permissive execution environment, which is why Conifers starts with architectural boundaries and layers governance on top. Governance is one of the eight requirements of an enterprise-ready AI SOC. As organizations move to human-on-the-loop operations, the nature of oversight also changes.
What did OpenAI find about AI agents and internet access?
OpenAI’s findings came from securing its own frontier AI environment: internet access introduces significant risks for autonomous AI agents, and restricting that access needs to be a fundamental part of their security architecture. That aligns closely with the first of the five decisions described above: Conifers’ security operations agents run with no direct internet access.
How Is an agentic SOC different from using a coding agent for security work?
An agentic SOC relies on autonomous agents to perform security operations across an enterprise, while a coding agent on a practitioner’s machine improves individual productivity. The first requires a different level of engineering discipline: isolated execution, controlled access, disposable agents and auditable reasoning. For more, read about how the agentic SOC evolved from copilots to autonomous agents and what an autonomous SOC looks like in practice.