TL;DR. DigitalOcean opened Managed Agents to public preview: Harness Runtime, Firecracker microVM sessions that pause, resume, and fork, and Action Gateway, a managed MCP endpoint onto a catalog of thousands of tools. One line in the announcement does more security work than the rest of it: "Credentials are brokered at execution time and never reach the model or sandbox." That closes the bypass every gateway before it had to footnote, because an agent that never holds a credential cannot walk around the gateway with it. What brokering does not change is what the credential may do once the gateway exercises it. For the Snowflake and Supabase connectors in the catalog, that is the whole grant, on every call.
DigitalOcean announced the public preview of DigitalOcean Managed Agents on September 22, 2026, after a private preview, and InfoQ covered it on October 2. The pitch is infrastructure: run your agent harness (OpenCode, Codex CLI, Claude Code, LangGraph, or any custom OCI container image) inside a managed microVM, and hand it tools through one MCP endpoint instead of a folder of API keys. The coverage so far reads it as an ops story, faster sessions and per-second billing. The more consequential part is an access-control decision, and it is the one this post is about: in Managed Agents, the agent never holds a credential at all.
Two services, one preview
Harness Runtime is the execution half. Each session runs inside a dedicated Firecracker microVM with its own compute and filesystem, and lifecycle APIs persist conversational history and working state across sessions, with pause, resume, and fork semantics on top. DigitalOcean's own benchmark numbers are startup-shaped: a session is ready in 886 milliseconds, a resumed one in 305, and CPU billing follows actual consumption, so a paused session keeps its state while its CPU charge falls to zero.
Action Gateway is the access half. It is a managed MCP endpoint that, in the announcement's words, gives agents "governed access to 16,000+ tools across 500+ providers": web search, browser automation, DigitalOcean's own infrastructure APIs, and connectors for GitHub, HubSpot, Stripe, PagerDuty, Box, Exa, and, the ones that matter for this blog, Snowflake and Supabase. Teams can register their own MCP servers into the same catalog, and the gateway also serves MCP-compatible applications outside Harness Runtime. A tool-matching layer picks relevant tools per task rather than loading the catalog into context, which DigitalOcean's internal testing puts at 99.3% accuracy.
So the preview bundles the two things an agent platform has to supply, a place to run and a way to act, and puts a governance layer on the second: centralized permissions define the tools and actions available to each agent, with human approval available for sensitive operations.
The brokered credential closes a real hole
Every data-access gateway to date has carried the same asterisk. When CData launched Connect AI Gateway two weeks before this, we traced its enforcement span and found the boundary immediately: record-level policy holds for every request the gateway mediates, and an agent that acquires its own connection string never crosses the gateway at all. The enforcement was real; the routing was optional. That asterisk is not a design flaw in any one product. It follows from handing the agent a credential and then asking it to please use the governed path.
Managed Agents removes the premise. Credentials for connected tools live with the gateway, are "brokered at execution time and never reach the model or sandbox", and arrive by API key, shared OAuth, or per-user OAuth, with the gateway pausing a workflow on a sign-in link when a human has to authorize. There is no connection string in the microVM to exfiltrate, no environment variable for a prompt-injected agent to echo into a tool call, nothing for a compromised dependency to read. The governed path is not the recommended route; for brokered tools, it is the only route that works.
The scope of that sentence is worth stating as precisely as the sentence itself. It covers tools connected through Action Gateway. A team that mounts a database password into its custom container image, or registers its own MCP server that holds credentials internally, has rebuilt the old path beside the new one. Brokering is a property of the connection, not of the estate: it is only as complete as the migration of every credential into the broker.
What the gateway rules on, and what the credential still does
Now follow one brokered call the rest of the way. The permissions model governs, per agent, which tools are available and which actions are allowed, and can require a human approval before a sensitive one. Every one of those controls rules on the tool call: its name, its action, its presence in this agent's catalog. For a Snowflake or Supabase connector, the action that survives all three checks is, in substance, "run this query as the connected credential."
What that query may touch was decided earlier, somewhere else: when the credential was created and granted inside the database. If the connected Snowflake user can read forty tables, every approved call can. The gateway's permission entry does not narrow it; the approval prompt shows a human the action, not the plan or the rows; and the brokered secret is exercised whole. This is the distinction we drew when Mem0's gateway separated connecting a tool from granting it: a connection is binary, a grant has width, and governing the first says nothing about the second. It is also where Microsoft landed from the opposite direction when its Postgres MCP server declined to claim any enforcement span: role permissions remain the boundary, and the component in front of the database rules on something coarser than what the database executes.
Brokering, in other words, moves the credential out of the blast radius without shrinking the blast radius. The hole it closes is possession. The span it leaves is everything the possessed thing was ever allowed to do.
The gateway rules on the call. The grant decides the span. Brokering deletes the bypass arrow and leaves the bar exactly as wide as it was.
Fork copies what the agent already read
The runtime half has a governance consequence of its own, and nothing in the preview's permissions model addresses it. Harness Runtime persists "conversational history and working state across sessions", and fork turns one session into two. Whatever an agent has read is part of that state: the result set a Snowflake call returned an hour ago is in the context that pauses at no CPU charge, resumes in 305 milliseconds, and duplicates into every fork.
Access control, meanwhile, lives entirely at call time. Revoke the credential's grant tonight and tomorrow's calls fail, as they should; the rows already read remain in every snapshot and branch that descends from the session that read them, retrievable by whatever that fork does next. We measured a version of this window in stale authorization for AI agents on databases: between a permission change and its enforcement, agents act on authority they no longer have. Session persistence extends the same window from minutes to the lifetime of a snapshot, and fork multiplies the copies. Fresh research is converging on the gap from the memory side: a paper posted to arXiv on October 5 proposes attaching a full derivation lineage to every cached result and gating retrieval on the columns it derives from, precisely because a cached answer otherwise outlives the permissions that produced it. Tool-level and action-level permissions, the preview's vocabulary, have no noun for any of this: the governed unit is the call, and the accumulating state is nobody's.
None of this argues against the design. Brokered credentials are the right default, and the platforms that still hand agents raw connection strings should feel the pressure of this preview. The preview label deserves its usual weight, the benchmark numbers are DigitalOcean's own, and the permissions model may well grow finer nouns before GA. The point is what the architecture, taken at its word, rules on today: the call, not the query; the tool, not the grant; the session, not the state it accumulates.
Where Datapace fits
Datapace is building the layer those three gaps point at: a semantic context layer for AI on databases, with resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. A brokered credential that can do everything its grant allows is exactly where a policy gate that reads the query against the estate's meaning belongs. If your agents are getting a gateway this quarter, safe AI database access is the conversation to have before the credential connects.
The credential question had an honest answer this month, and DigitalOcean gave it: take the secret away from the agent. The grant question is still open, because it cannot be answered at a gateway. It is answered where the width of what a credential may do is defined, and where a query's reach is visible: at the database, against what the data means.
Sources
- DigitalOcean, Introducing DigitalOcean Managed Agents, September 22, 2026 (public preview, Harness Runtime and Action Gateway, Firecracker microVMs, pause/resume/fork, credential brokering quote, connector list, 886ms/305ms benchmarks, CPU-consumption billing, 99.3% tool matching, permissions and approvals).
- DigitalOcean Docs, Managed Agents public preview release note (components, DigitalOcean-maintained tools, third-party connectors, custom OCI sandbox templates, extending the catalog with your own MCP servers).
- InfoQ, DigitalOcean launches Managed Agents, October 2, 2026 (coverage framing, supported harnesses, session persistence across pauses, resumes, and forks).
- arXiv, Lineage-Aware Memory Governance: A Derivation-Gated Framework for Privacy-Preserving Column-Level Access Control in Enterprise AI Agents, October 5, 2026 (abstract: lineage attached to cached results, retrieval gated on derived columns).