DigitalOcean Managed Agents Use Three Config Layers to Fence In AI Agents
DigitalOcean says its Managed Agents platform, now in public preview, limits what an AI agent can do through three configuration layers: hidden credentials, a read-only filesystem posture and a network allowlist. The company described the setup in a blog post built around a real migration of huffl's production backend from Supabase to DigitalOcean.
- DigitalOcean Managed Agents, in public preview, use three config layers to limit agent behavior: credentials, filesystem and network.
- An agent migrated huffl.ai's backend (31 tables, 145,432 rows, about 31,000 vector embeddings) from Supabase to DigitalOcean.
- Action Gateway attaches credentials at call time, so tokens never pass through the model, prompt or transcript.
- The NVIDIA OpenShell policy profile openshell-default makes the filesystem read-only except /workspace, /tmp and /dev/null.
- Network access is deny-by-default with an allow_hosts list enforced by a proxy; customers remain responsible for securing connected workloads, data and tools.
A production migration run from a phone
According to DigitalOcean, a Managed Agent recently handled the move of the backend behind huffl.ai, which the company describes as a real product. The backend consists of 31 tables, 145,432 rows, three storage buckets and about 31,000 vector embeddings. The agent provisioned the database, loaded the access policies, mapped each Supabase feature to its DigitalOcean counterpart and verified the data table by table. It was directed from a phone in plain chat.
The author, Rohit Bhattacharjee, argues that this kind of convenience is not a security model. For days the agent had access to two clouds and touched production data throughout. The post focuses on how it stayed within its limits.
DigitalOcean Managed Agents is the company's platform for running AI agents in production. Harness Runtime gives every session its own Firecracker microVM, and sessions can keep running, pause, resume and fork after a laptop is closed. Action Gateway offers one managed MCP endpoint to more than 16,000 tools as of October 2026, with credentials brokered at the moment of the call and human approval available for sensitive actions. The platform is open by default, so users can bring their own harness, model or key. Preview products come without a service level agreement, and features may change or be withdrawn before general availability, according to DigitalOcean.
Layer one: credentials the agent never holds
The first boundary concerns secrets. Instead of pasting tokens into a prompt or environment variables, the team connected the DigitalOcean token through Action Gateway as a managed OAuth connection. No key was typed, pasted or uploaded in the session.
When the agent decides to call the DigitalOcean API, it builds the call, and Action Gateway attaches the credential at the moment of the request. The result then comes back. According to DigitalOcean, the token never passes through the model, the prompt or the transcript. The agent can use the credential but is not given its value.
The company says it checked this. In the demo session, the agent audited its own environment mid-session and the values came back redacted. The sandbox held neither a DigitalOcean token nor a Supabase token.
Layers two and three: filesystem and network
The second layer is the NVIDIA OpenShell open source runtime, which defines a default posture for agent sandboxes covering the filesystem, the network and what stays locked. In the console, users click Import environment.yaml, choose the OpenShell template, and the manifest sets policy_profile: openshell-default. The filesystem is read-only, with writes allowed only to /workspace, /tmp and /dev/null.
DigitalOcean tested the setup by asking the agent to create a file in /bin. The agent asked a human for approval, tried anyway and received "Permission denied." A sudo check also failed. The agent then explained the boundary and offered to put the file in /tmp instead. The company stresses that the enforcement comes from Harness Runtime using the OpenShell policy profile, not from the agent behaving well.
The third layer is egress. The manifest locks allow_hosts to the hosts the job needs, and the proxy refuses any other connection. This follows OpenShell's default posture of deny-by-default network access with an explicit allowlist. The list is declared upfront rather than monitored by people.
What it means for users
DigitalOcean says Managed Agents enforce the OpenShell posture natively through Harness Runtime, with no extra tooling or bolt-on policies. Users connect their tools, select the OpenShell profile, and the boundaries are set before the agent writes its first line.
The company also draws a limit on its own role: configuring these boundaries is the platform's job, while securing the workloads, data and tools connected to an agent remains the customer's responsibility. Managed Agents is available in public preview.
