Three layers, all config: how DigitalOcean Managed Agents enforce NVIDIA OpenShell-aligned boundaries

A few weeks ago, we handed an AI agent one of the scariest jobs in infrastructure: moving huffl’s production backend from Supabase to DigitalOcean.

huffl.ai is a real product. Underneath it sits 31 tables, 145,432 rows, three storage buckets, and about 31,000 vector embeddings. A DigitalOcean Managed Agent did the migration, directed from a phone in plain chat. It provisioned the database, loaded the access policies, mapped every Supabase feature to its DigitalOcean counterpart, and verified the data table by table.

There is something magical about watching that happen. A message typed while waiting for coffee. A decision made between meetings. No laptop, no terminal, no maintenance window. By the end of the week the backend had moved, and nobody worked a late night.

But magic is not a security model. For days, the agent had the run of two clouds and touched production data the entire time. What is worth examining is how it stayed inside its boundaries while doing it: how to hand an agent that much power without handing it a key, and how to draw lines it cannot cross. Three layers. All config.

What is DigitalOcean Managed Agents?

DigitalOcean Managed Agents is our platform for running AI agents in production, now in public preview, so you don’t have to build the plumbing yourself. Public preview products are provided without a service level agreement and are subject to the DigitalOcean preview terms; features may change or be withdrawn before general availability. DigitalOcean Harness Runtime gives every session its own Firecracker microVM, and sessions keep running, pause, resume, and fork even after you close your laptop. Action Gateway gives agents 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. It runs on the DigitalOcean AI-Native Cloud and is open by default, so you bring your own harness, model, or key. Here’s how it stayed inside its boundaries on a real migration.

1. The credential stays out of the agent’s hands

To migrate a backend, the agent needs API access to two clouds. The naive move is the one everyone makes first: paste the tokens into the prompt, or drop them in environment variables, and hope they never surface in a transcript or a log file.

We connected the DigitalOcean token through Action Gateway as a managed OAuth connection instead. Click, authorize, done. No key was typed, pasted, or uploaded in this session.

Here is what happens instead. The agent decides to call the DigitalOcean API and builds the call. Action Gateway attaches the credential at the moment of the call and sends it on. The result comes back. The token never passes through the model, the prompt, or the transcript. The agent can use the credential. It is not given access to the credential value itself.

We checked. In the session shown in the demo, the agent audited its own environment mid-session, and the values came back redacted. The sandbox held no DigitalOcean token and no Supabase token in that session. The proof is not that the agent behaved. The proof is that there was nothing in its hands to misbehave with.

2. An NVIDIA OpenShell policy profile

Credentials were the first boundary. The second is what the agent is allowed to touch once it is running. NVIDIA OpenShell open source runtime defines a default posture for agent sandboxes: what the filesystem allows, what the network permits, what stays locked. DigitalOcean Managed Agents ship with that posture built in. You select it in the console before the session starts.

In the console you click Import environment.yaml, choose the OpenShell template, and the manifest sets policy_profile: openshell-default:

policy_profile: openshell-default
permissions:
  filesystem:
    mode: read-only
    allow_write:
      - /workspace
      - /tmp
      - /dev/null

Save, create the session, and the agent runs inside that shape.

Then we tested the shape. The agent was asked to create a file in /bin. It thought about it, asked a human for approval, tried anyway, and got “Permission denied.” The agent tried a sudo check. That failed too. Then it did the most telling thing in the whole session: it explained the boundary itself, and offered to put the file in /tmp instead.

The enforcement is not the agent behaving well. Harness Runtime enforces this, using an NVIDIA OpenShell policy profile.

The network has a guest list

The third boundary is egress. An agent with API access and no network boundary can reach anywhere on the internet. Ours could reach its guest list and nothing else.

The manifest locks allow_hosts to the hosts the job needs. If the agent reaches for anything else, the proxy refuses the connection. This follows OpenShell’s default posture: network access is deny-by-default, with an explicit allowlist. Like the other two, this is configuration, not vigilance. Nobody watches the traffic hoping to catch it. The list is declared upfront, and connections not to hosts on it are refused.

Three layers, all config

Credentials that stay out of the agent’s hand. A filesystem posture declared in the manifest and enforced by the runtime. A network guest list the proxy enforces. The agent did real work against a production backend, and the filesystem and network posture comes from the NVIDIA OpenShell open source runtime. DigitalOcean Managed Agents enforce it natively through Harness Runtime. No extra tooling, no bolt-on policies. Connect your tools, select the OpenShell profile, and the boundaries are set before the agent writes its first line. Configuring these boundaries is the platform’s role; securing the workloads, data and tools you connect to an agent remains yours.

The agent moved a production backend onto DigitalOcean, and the platform it ran on set the limits it worked within.

Try DigitalOcean Managed Agents in public preview today. Bring your preferred harness, connect your tools, and give your agents an environment with boundaries you can state up front.

NVIDIA and OpenShell are trademarks of NVIDIA Corporation. Supabase is a trademark of Supabase, Inc. All other marks are the property of their respective owners. References to third-party products are for identification only and do not imply affiliation with or endorsement by those companies.