How DigitalOcean Manages Credentials for Autonomous Agents

** Built to align with NVIDIA’s Agent Safety Platform strategy for securing autonomous agents When an agent handles confidential material, it needs enough access to do the job and nothing else. The hard part isn’t giving an agent that access, it is having confidence that if the agent misreads a task, gets prompt injected, or calls the wrong tool, there’s no live credential sitting in its reach for it to leak, misuse or hand-off. DigitalOcean supports Nvidia’s Agent Safety Platform strategy for securing agent runtimes, and the credential architecture behind Digital Ocean’s Managed Agents is where that alignment is most concrete: permissions and network controls designed to fit Nvidia OpenShell’s open policy schema, with the agent itself never holding a secret in the first place. The problem with secrets living inside the agent Traditional applications lean on human-managed vaults or long-lived environment variables. Autonomous agents break that model; a raw secret sitting inside an .env file or application code inside an agent’s own execution context is one bad prompt, one compromised dependency, or one unauthorized tool call away from exposure. Constraining the agent’s behavior; better prompts, tighter guardrails, doesn’t fix this, because the exposure exists the moment the credential is inside the agent’s environment at all. DigitalOcean’s approach starts from a different assumption: the agent should never hold the secret in the first place. Ephemeral, execution-time credentials DigitalOcean Managed Agents runs every agent in an isolated harness session on DigitalOcean Harness Runtime. Inside that session, the agent has no standing credentials of its own, no API keys, no tokens, nothing persisted in its filesystem or memory that could be read out or exfiltrated. When the agent needs to take an action that requires authorization such as reading an internal access controlled document, querying a system, that call goes through DigitalOcean Action Gateway instead of the agent holding the key itself. Credentials are brokered at execution time and never reach the model or the sandbox. The Action Gateway serves as the intermediary component within Managed Agents, bridging the gap between autonomous workloads and over 16,000 available integrations. Its operational security foundation relies on three key mechanisms: Actor management. Every tool connection is tied to who the agent is acting on behalf of; an API key, a shared OAuth app, or per-user OAuth; so access is attributable to a specific actor rather than a single undifferentiated agent identity. This allows teams to scope one agent’s access per end user, instead of granting one broad credential the agent uses for everyone. Tool call initiation. Credentials are brokered at execution time and never reach the model or the sandbox. The agent asks Action Gateway to make the call; Action Gateway injects the credential at that moment, and the agent never sees the key. Refresh flows. When authorization is needed mid-workflow; a token expires, a new scope is required; Action Gateway handles it without handing the agent a refresh token to manage itself: it surfaces a sign-in link when needed and resumes the call once authorization completes, so long-running or multi-step work doesn’t require the agent to hold or refresh a secret on its own. Put together, these three are what let an agent do real, multi-step work against real systems; reading a document store, opening a ticket, querying a database, without the credential for any of it ever living where the agent’s own reasoning could reach it. This is the same underlying pattern NVIDIA is putting forward with OpenShell’s open policy schema, declarative, externally enforced boundaries rather than trust placed in the agent itself. image caption ** Deep Dive: Securing an Internal Document Auditor Consider an automated compliance auditor designed to audit internal documents, scan unreleased vendor contracts, and check compliance rules against regulatory frameworks. 1. Declaring Intent with DigitalOcean Managed Agents At the orchestration layer, DigitalOcean establishes a read-only harness session. The agent is granted explicit access to read target contract files, but is denied general write operations or untrusted tool execution: # DigitalOcean Harness Spec Fragment permissions: default: deny filesystem: read-only rules: - tool: file.read - match: { path: "/workspace/contracts/**" } - action: allow secrets: MY_MCP_TOKEN: ${MY_MCP_TOKEN} egress: - mcp.example.com 2. Enforcing Runtime Boundaries Designed to Fit OpenShell DigitalOcean passes this intent specification down to runtime enforcement rules designed to fit OpenShell’s open policy schema: VPC-Level Zero-Egress Network Isolation: The read-only spec maps directly into microVM firewall rules (network_policies: deny_all), preventing python or node runtime processes from opening outbound sockets. Even if an underlying document-parsing library contains a vulnerability or compromised dependency, the agent cannot transmit sensitive data or credentials to external servers. Non-Root Runtime Enforcement: Sandbox process identities are pinned to non-root specifications (uid: 1000, gid: 1000). If a malicious payload attempts privilege escalation inside a document parser, file system write access to system directories remains blocked by the kernel. Open Standards for Safe Agent Autonomy By combining DigitalOcean’s intent-driven agent orchestration with policy specifications following the same pattern as OpenShell, customers no longer have to compromise between agent capability and security risk. Security Layer Enforcement Component Enterprise Benefit Intent Layer DigitalOcean Harness Runtime & Action Gateway Human-in-the-loop approvals, ephemeral secret injection, and scoped tool permissions. Runtime Layer OpenShell Policy Schema & MicroVM Sandboxes VPC zero-egress network isolation, non-root execution, and default-deny filesystem rules. Zero Exfiltration & Secret Exposure: Sensitive documents and credentials are processed inside VPC-isolated, zero-egress sandboxes. Actionable Audit: Every allow and deny decision lands in an audit trail that security teams can inspect and act on. Built in the Open: Built on open-source Plano, the underlying policy models remain open and inspectable by the broader community. As autonomous agents take on core business operations, DigitalOcean is committed to providing cloud infrastructure where agentic workflows run safely, predictably, and securely within clear, declarative boundaries. **

Source: DigitalOcean | 2026-09-28

Related