How Cogent Runs Cloud Agents Securely

At Cogent, we assume any cloud agent may be compromised and have built our infrastructure around that assumption. This assume-the-worst mentality is imperative because customers trust our agents with sensitive security data to contextualize, prioritize, and remediate vulnerabilities in their environment. These agents use tools and execute code in isolated cloud microVMs (sandboxes), often without real-time human supervision. Building them for autonomous cyber defense and internal development has taught us that the infrastructure around each sandbox must both constrain the agent and equip it to work.

That autonomy creates leverage. Cloud agents can take on long-horizon tasks, work in parallel, and run in the background, with each job in an isolated environment rather than on a person's machine. For Cogent, this lets customer-facing agents keep customers' security context current, and enables internal agents to continue development work beyond an engineer's laptop session.

Recent incidents show why those constraints matter. OpenAI's account of the Hugging Face incident describes agents chaining vulnerabilities to escape their sandboxes. Reuters also reported OpenAI agents coordinating through a German wiki site that allowed communal edits via GET requests, working around a POST restriction on their sandboxes. The exact techniques will change as models improve, but the lesson will not: controls that depend on the agent choosing to behave are not security boundaries.

Zero trust with agents, even when their task is trusted

Even a well-intentioned agent can follow a prompt injection, execute a compromised dependency, misunderstand a task, or combine individually permitted actions in unexpected ways.

The lethal trifecta captures the core danger: an agent has access to private data, can consume untrusted content, and can communicate externally. Put all three in one environment and a prompt injection can become a data exfiltration path.

For our systems, that broad risk becomes a concrete threat model:

• Prompt injection: adversarial content can redirect an agent toward running untrusted code, revealing data, or taking an unintended action.

• Compromised dependencies: a package installed during a task can execute malicious code inside the sandbox.

• Overly broad tools: a valid tool call can still be dangerous if the agent has more permissions than those required for its task.

• Credential exposure: any plaintext secret available to the agent can be read through the terminal, logged, or sent elsewhere.

• Cross-tenant access: a sandbox that can resolve another tenant's services creates an unacceptable path across the tenant isolation boundary.

• Shared kernels: containerizing an agent isolates at the software layer, but a kernel compromise can still expose the filesystems, credentials, and allowed network paths of neighboring containerized workloads.

This led to a simple design rule: assume the code and agent inside a sandbox can be compromised. Identity, credentials, network policy, and authorization must be controlled by trusted systems outside it.

The secure boundary must sit outside the agent

Let's walk through a cloud agent's task from start to finish to see how our infrastructure limits those risks. An interactive session, automation, or our internal CLI first requests a sandbox. Before creation, our trusted sandbox control plane assigns an identity tied to the tenant, user, agent, and task from the incoming request. That assignment determines which capabilities the sandbox may receive. The agent itself cannot claim another tenant or elevate its privileges from inside the sandbox. This extends the identity model from our earlier Agent Development Platform post.

The control plane then chooses the sandbox’s scanned, pinned image, fixed lifetime, and deny-by-default network egress policy admitting only hostnames needed for the task. The assigned capabilities also limit which credentials the agent may use; only sandbox-bound stubs are injected, never secrets. A credential proxy holds the real values and uses them on authorized outbound requests. This allows the agent to make API requests without ever being able to read real secrets or exfiltrate them on the internet. If the required network policy cannot be applied or credential stubs cannot be injected, sandbox creation fails rather than proceeding without those security controls.

On creation, a bare-metal hypervisor gives each sandbox its own kernel for hardware-level isolation, so compromising one kernel does not by itself compromise another. Each sandbox also sits inside a Cogent VPC with no inbound path from the internet to reduce risk of external compromise.

The sandbox starts with its credential stubs already in place. The agent harness, reviewed skills, application code, and dependencies provide what the agent needs to perform and verify the work.

The setup also includes a short-lived signed JWT issued by the control plane for the tenant’s agent gateway. The gateway is a single MCP endpoint for the backend tools the agent needs. The token authenticates requests and carries claims the gateway checks to authorize each tool call before the tool runs. Two layers guard against cross-tenant tool access: each network policy may include a gateway for only one tenant, and each tenant has a separate gateway deployment serving only that tenant's tools and credentials. With this setup, the agent can receive tenant context and tool results without being able to read the customer credentials behind them.

Once the sandbox is ready, the agent begins work. If needed, users and services can request the control plane to pause or resume the sandbox, but the agent itself cannot extend its assigned lifetime. When the task ends, the control plane destroys the sandbox and its memory.

Since cloud agents often work unsupervised, we keep thorough records for review. We monitor sandbox processes and memory behavior, and trace agent turns and tool calls with tenant, user, agent, and task attribution. These records help us spot behavior outside the assigned task boundaries, evaluate output quality, and see where missing capabilities kept the agent from verifying its work.

Strong boundaries make useful autonomy possible

The same cloud agent infrastructure supports both autonomous cyber defense and internal software development, without collapsing their privilege boundaries. The diagram below shows just a few of the workflows that this infrastructure has made possible not just for our customers, but also for us at Cogent.

Better agents come from better execution environments

We learned early that a cloud agent without the development environment its task requires is mostly guessing. An agent asked to change a backend service needs to run that service and its tests locally. An agent changing a frontend needs a browser. Without those feedback loops, it can produce plausible code but cannot prove that the result works.

The same lesson is even more important for vulnerability remediation. An agent cannot confirm that a vulnerability is exploitable, validate a proof of concept, or verify an attack path if it cannot run the relevant services locally or access a non-production test target. Reliable remediation depends on the right source code, dependencies, configuration, tools, and carefully scoped access.

In Cogent's application security remediation workflow, for example, a customer-facing cloud agent starts from a scanner finding. On a human request or customer-configured trigger, it prepares a candidate fix against the recorded source revision and runs targeted tests. The same agent then checks whether the exploit still works and looks for newly introduced vulnerabilities, validating against a local service or another non-production target where possible. Without the application's dependencies, the agent cannot run the appropriate unit tests. Without a non-production test target, it cannot show that the exploit was eliminated in a running application. If the execution environment is lacking, presenting an unverified fix as validated can create false confidence that the scanner finding is resolved.

The goal is to provide the minimally sufficient environment for the task: enough local services, credentials, and network access to execute and verify the work, with each capability constrained outside the sandbox. Better agent output and tighter security come from curating that environment together.

This is why building cloud agents has felt more like an infrastructure engineering problem than an agent engineering problem. Model capability matters, but the surrounding system determines whether that capability is useful, verifiable, and safe.

The safest cloud agents are constrained, equipped, and observable

Cloud agents create meaningful leverage for continuous cyber defense and internal development. Realizing that leverage requires four things at once: isolation that limits the blast radius, trusted systems that control identity and authority, an execution environment rich enough for the agent to verify its own work, and traces that show what it actually did.

With more than 400,000 sandbox instances tracked by our control plane as of September 2026, these are everyday operating requirements. No individual control is sufficient. Kernel isolation without network policy still permits exfiltration. A tenant-specific gateway without identity-based authorization can expose too many tools. Strict restrictions without a runnable application leave the agent unable to validate its result. Without observability into agent turns and tool calls, we cannot review its actions and make improvements for subsequent agent runs.

The architecture has to do both jobs: contain what can go wrong and make correct work possible. With those foundations in place, cloud agents can operate at scale on sensitive security problems without asking us to trust the agent as the security boundary.