When agent infrastructure becomes a control plane
DigitalOcean Managed Agents brings execution, sessions, tools, permissions and runtime evidence into one service. The assurance question is whether that makes agent behaviour easier to govern, or concentrates too much trust in one provider.
The interesting part of DigitalOcean Managed Agents is not that it can run another coding agent.
It is that agent infrastructure is starting to package execution, memory, tools, permissions and evidence together.
Agent infrastructure is becoming a control plane
DigitalOcean describes Managed Agents as two connected services: Harness Runtime runs the agent, while Action Gateway governs its tool calls.
See its architecture overview.
The runtime provides an isolated microVM, coding tools and durable sessions. A session can pause, resume or fork with its working state preserved.
The gateway provides a managed endpoint for more than 16,000 tools. Credentials are resolved when a tool runs, rather than passed into the agent or sandbox.
DigitalOcean says its Inference Engine can route to more than 75 open and proprietary models.
See DigitalOcean's launch announcement for these vendor counts.
DigitalOcean's internal benchmark reports a 305 ms runtime resume-to-readiness result.
Treat it as vendor evidence, not an independent comparison.
That packaging matters because assurance evidence often fragments across the agent, tool integrations, credentials, session store and logs.
DigitalOcean says its runtime events record model requests, tool calls, file operations and approval activity.
That can provide a more useful review trail than prompts alone.
A gateway creates review points, not governance by itself
The gateway can allow a call, require approval or deny it. The customer defines the policy and remains responsible for matching it to the agent's intended work.
See DigitalOcean's tool policy documentation.
DigitalOcean warns that a broad allow rule can permit account changes, writes and deletions without a prompt. A tool policy also does not narrow the provider credential's own scope.
Approval depends on the client completing the flow. DigitalOcean says to verify the behaviour with the deployed adapter; an MCP connection alone does not guarantee an inline approval prompt.
See its server-side approval guide.
These are useful enforcement points, but they do not remove the need to limit provider scopes, select only required tools and deny actions that must never run.
That separation aligns with OWASP's AI Agent Security guidance.
OWASP recommends granting only required tools, scoping permissions per tool and requiring explicit authorisation for sensitive operations.
The NIST NCCoE agent identity project likewise frames agent identity and authorisation as work that organisations still need to implement.
What to verify before expanding autonomy
Start with read-only access and a short list of selected tools. Confirm the effective policy for each call, including arguments that change an operation from a read into a write.
Exercise approval, denial, timeout and retry paths with the exact client and adapter you plan to deploy. Verify that an approval applies only to the intended call and that the agent cannot approve itself.
Inspect what the event trail captures, who can read it, how long it is retained and whether sensitive values are redacted. An event stream is useful only if reviewers can access it when needed.
Test checkpoint boundaries before forking sessions. Confirm that one branch cannot inherit another branch's credentials, permissions or sensitive state unexpectedly.
Finally, test recovery: a failed tool call, expired approval, interrupted session or unavailable provider. Define who can stop the agent and how to reconcile partial external changes.
These are assurance checks, not claims that DigitalOcean lacks the controls. They establish whether the controls behave as your deployment requires.
What this preview does and does not establish
DigitalOcean reports its own latency and tool-selection results. Its benchmark is useful product evidence, but the vendor chose the setup and measured the outcomes.
Managed Agents is in public preview. DigitalOcean Insights, the cross-service observability layer, is in private preview; Signals is described as coming soon.
That means the packaging is promising, but the complete evidence experience is not generally available today. Review the current product boundaries before relying on it for an assurance obligation.
Bringing runtime, tools and evidence into one control plane may make agent behaviour easier to review. It may also concentrate operational dependence and assurance trust in one provider.
The practical decision is to map which controls remain yours, which evidence you can export and what happens if the provider or its observability service is unavailable.
Does bringing runtime, tools and evidence into one control plane make agents easier to govern, or does it concentrate too much trust in one provider?
Follow the original launch material
DigitalOcean · Updated 22 September 2026 · 11 min read
Introducing DigitalOcean Managed Agents
The full product article covers architecture, pricing, benchmark method and the Qencode case study.
