DigitalOcean Keeps Credentials Out of Reach of Autonomous AI Agents

Why secrets inside the agent are a risk

In a post by Tyler Healy, DigitalOcean opens with an agent that investigates a duplicate charge. It reads a customer email, checks billing history, issues a refund and updates a support ticket. That workflow needs access to confidential data and permission to change business records, and at thousands of tickets a day, reviewing every intermediate action would defeat the purpose of automation.

The danger, the company says, is that the agent meets untrusted content while holding that authority. A customer attachment could contain text disguised as an internal procedure, asking the agent to upload payment history to a diagnostic endpoint. A coding agent faces a similar risk if instructions in a repository persuade it to upload source code or expose credentials.

DigitalOcean argues that better prompts and tighter guardrails do not solve this, because the exposure exists as soon as a credential sits inside the agent's environment. Its approach starts from the assumption that the agent should never hold the secret in the first place.

Action Gateway brokers credentials at execution time

According to DigitalOcean, Managed Agents runs every agent in an isolated harness session on DigitalOcean Harness Runtime. Inside that session the agent has no standing credentials: no API keys, no tokens, nothing persisted in its filesystem or memory. When it needs an authorized action, the call goes through DigitalOcean Action Gateway, which sits between autonomous workloads and over 16,000 available integrations.

The company lists three mechanisms behind it:

• Actor management. Every tool connection is tied to the party the agent acts for, such as an API key, a shared OAuth app or per-user OAuth. Access is attributable to a specific actor, and teams can scope an agent's access per end user.
• Tool call initiation. The agent asks Action Gateway to make the call, and the gateway injects the credential at that moment. The agent never sees the key.
• Refresh flows. If a token expires or a new scope is needed mid-workflow, Action Gateway surfaces a sign-in link and resumes the call once authorization completes, without handing the agent a refresh token.

Network controls add a separate layer. In the refund example, a request to an unapproved diagnostic endpoint can be blocked even if the agent has been persuaded the upload is necessary. DigitalOcean says its permissions and network controls are designed to align with NVIDIA OpenShell's open policy schema, so security teams can review and version those boundaries alongside the configuration that defines the agent's work.

When an agent needs its own key

Not every workload fits Action Gateway, for example a private MCP server, an internal API or a model endpoint outside the catalog. For these, DigitalOcean says Harness Runtime makes the declaration itself the security boundary. How a value is written into the environment spec decides who can read it back, and the three options are deliberately not equivalent.

• env is for configuration such as model tiers, endpoints and feature flags. Values are kept verbatim in the saved spec and returned in API responses to anyone who can read the environment. Harness Runtime scans submitted specs for credential-shaped names (*_API_KEY, *_TOKEN, *_PAT) and known prefixes (sk-, ghp_, dop_v1_, AKIA) and flags them.
• secrets moves the value into a managed secret store, encrypted at rest, stripped from the saved spec and absent from API responses, the event stream and the Control Panel. The real value is still injected as an environment variable, so the agent and any process it starts can read it.
• Scoped secrets add a url to the slot, binding the credential to a single HTTPS destination. The sandbox receives a short-lived authorization handle under the same variable name, and when the agent calls the bound host, the egress proxy redeems the handle and attaches the real credential.

Sub-agent swarms (Beta)

DigitalOcean also describes swarms, in beta, such as a compliance auditor that fans out to one sub-agent per contract plus others for summaries and regulatory queries. In Harness Runtime each sub-agent is its own session with its own microVM, workspace, event history and session ID. The company contrasts this with the usual swarm design, where fan-out means more threads sharing one memory space and one set of environment variables.

Siblings share nothing by default, so a sub-agent parsing a contract cannot read the workspace of the one summarizing it. A child session is created from an environment and its credentials are resolved from the secret store at start. According to DigitalOcean, that gives "what does this sub-agent have access to?" a recorded answer in the control plane, and each session keeps a record of which secrets it declared and where they came from, making a swarm auditable after the fact.

What it means for teams running agents

For teams deploying agents on the platform, the claim is that a compromised or manipulated agent has no reusable key to expose, since credentials are injected outside the sandbox and outbound destinations are restricted separately. Because the boundaries are declarative, security teams can review and version them with the agent's configuration. The source is the company's own description, and it does not include independent testing or pricing details.