←All Posts
managed-agentsscheduled-deploymentsvault-backed-envcredential-injectionai-agents

Sandbox0 Managed Agents: Scheduled Deployments and Vault-Backed Environment Variables

Sandbox0 Team·

Anthropic's June 9 update to Claude Managed Agents made two backend primitives much more visible: scheduled deployments and environment variable credentials in vaults.

Those two features look small if you read them as product UI:

  • run an agent on a cron schedule
  • let a CLI read an API key from an environment variable

They are not small at the infrastructure layer.

Scheduled deployments answer the trigger problem: how does an agent start work when no user is actively pressing a button?

Vault-backed environment variables answer the credential problem: how does an agent use existing CLIs, SDKs, and HTTP clients without placing real secrets inside the sandbox process?

Sandbox0 Managed Agents now supports the same shape of workflow for Sandbox0-owned managed agent sessions. You can use the official Anthropic SDK against the Sandbox0 Managed Agents endpoint, create deployments with cron schedules, inspect deployment runs, trigger manual runs, and attach vault credentials that expose placeholders to the sandbox while resolving real secret values at the network boundary.

This is the direction managed agents are heading: less glue code around the model, and more runtime infrastructure behind the API.

Why This Matters#

Most production agent work is not purely interactive.

Useful agents often need to:

  • refresh a daily account summary
  • run a weekly compliance scan
  • check production metrics every morning
  • rebuild a browser-skill catalog
  • open a recurring repository maintenance task
  • generate a report after data has landed
  • follow up on customer or recruiting workflows

Before scheduled deployments, teams usually had to build a normal job scheduler beside the agent backend. A cron job, queue worker, workflow engine, or cloud function would wake up, call the agent API, pass the right environment, attach the right files, attach the right credentials, record the run, and decide what to do if session creation failed.

That is repeated infrastructure.

Before vault-backed environment variables, teams usually faced a bad choice for CLI-driven agent work:

  • put real API keys in sandbox environment variables
  • write custom MCP tools for every service
  • wrap every CLI with a proxy
  • avoid existing CLIs and reimplement API calls
  • trust the agent not to print or copy secrets

That is also repeated infrastructure.

Scheduled deployments and vault-backed environment variables remove a large amount of that glue from the application layer. They move it into the managed-agents backend, where scheduling, session creation, run history, credential storage, network policy, and runtime orchestration can be handled consistently.

What Claude Changed#

Anthropic's official announcement describes the two primitives directly.

A scheduled deployment gives an agent a cron schedule. Each scheduled fire creates a new session, so the deployment is the durable definition and each run is a concrete execution record. The docs also expose lifecycle controls: pause, unpause, archive, and manual run.

Environment variable credentials extend vaults beyond MCP credentials. A credential is keyed by secret_name, the sandbox receives an opaque placeholder under that environment variable name, and the real value is substituted at egress for allowed destinations. The official docs also call out the operational constraints that matter for implementation: sensitive values are write-only, secret_name is unique per vault among active credentials, and keys are immutable after creation.

The important market signal is not just that Claude added two endpoints. It is that scheduled work and secret brokering are now part of the public managed-agents contract.

What Sandbox0 Added#

Sandbox0 Managed Agents uses the same external shape:

  • deployments store the agent reference, environment, initial events, resources, vaults, metadata, and optional cron schedule
  • scheduled runs create new sessions from that deployment
  • deployment runs record trigger context, session id, and errors
  • manual runs use the same deployment definition without waiting for cron
  • pause suppresses future scheduled triggers while allowing manual runs
  • unpause resumes from the next scheduled occurrence
  • archive terminates the deployment lifecycle
  • vault-backed environment variables expose stable placeholders to the sandbox
  • Sandbox0 egress credential injection resolves the real secret outside the agent process

The implementation follows Sandbox0's existing boundary: the session and deployment state live in the Managed Agents control plane; tool execution happens in isolated Sandbox0 sandboxes; credentials are stored in vaults; network policy and placeholder replacement happen at the runtime boundary.

This is separate from Claude Managed Agents on Sandbox0. In that integration path, Anthropic owns the Claude Managed Agents control plane and Sandbox0 acts as a self-hosted sandbox provider. In Sandbox0 Managed Agents, Sandbox0 owns the managed session API and uses Sandbox0 runtime primitives underneath. If you are comparing the two product boundaries, see Claude Managed Agents vs Sandbox0 Managed Agents and Claude Managed Agents Alternative.

Scheduled Deployments#

A deployment is a reusable agent run definition.

It is not just a cron string. It stores the same inputs a session needs:

  • the pinned agent
  • the environment id
  • the initial user event that starts work
  • files or other resources
  • vault ids
  • metadata
  • an optional schedule

When the schedule is due, the scheduler creates a deployment run and starts a session. The run record is the audit trail for what happened: whether the trigger was manual or scheduled, which session was created, and whether session creation failed.

That distinction matters because recurring agents need two levels of truth:

ObjectResponsibility
DeploymentDurable definition of recurring work
Deployment runOne execution attempt from that definition
SessionThe agent's conversation, tool events, status, and output
SandboxThe runtime attachment that executes commands and file operations

The deployment survives across many sessions. Each run is a timestamped attempt. Each successful run points at a session. The sandbox is still replaceable runtime infrastructure, not the source of truth.

Example: A Weekday Agent Deployment#

The SDK shape is intentionally close to the official Managed Agents deployment resources. Application code can keep using the Anthropic SDK and point it at Sandbox0 Managed Agents:

javascript
import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic({
    baseURL: "https://agents.sandbox0.ai",
    apiKey: process.env.SANDBOX0_API_KEY,
});

const deployment = await client.beta.deployments.create({
    agent: agent.id,
    environment_id: environment.id,
    name: "weekday-health-digest",
    initial_events: [
        {
            type: "user.message",
            content: [
                {
                    type: "text",
                    text: "Review yesterday's production metrics and write a short health digest.",
                },
            ],
        },
    ],
    schedule: {
        type: "cron",
        expression: "0 9 * * 1-5",
        timezone: "UTC",
    },
    vault_ids: [llmVault.id, metricsVault.id],
});

await client.beta.deployments.run(deployment.id);

const runs = await client.beta.deploymentRuns.list({
    deployment_id: deployment.id,
});

The cron expression is five-field POSIX cron with an IANA timezone. Use manual runs to test the deployment before relying on the schedule. Use pause when you want to stop future scheduled triggers without deleting the definition. Use archive when the deployment is no longer part of the product.

Vault-Backed Environment Variables#

Environment variables are the integration path most existing CLIs and SDKs already understand.

That is useful, but a normal environment variable is also easy for an agent-generated command to read:

bash
printenv
cat /proc/self/environ

If the real API key is present in the sandbox, the agent can accidentally expose it, a dependency can read it, or a shell command can copy it into output.

Sandbox0's vault-backed environment variable path keeps the programming model but changes the security boundary.

The sandbox receives an environment variable such as SENTRY_AUTH_TOKEN, but its value is a stable opaque placeholder. The real secret_value remains in the vault. When a CLI or SDK sends that placeholder in an outbound HTTP request, Sandbox0's egress credential path can replace it with the real secret only for the configured networking scope.

Conceptually:

The agent can use the credential, but it does not hold the credential.

Example: A CLI Credential in a Vault#

Use environment_variable for service credentials that tools inside the sandbox need. Keep the model-provider credential in the LLM vault as static_bearer; vault-backed environment variables are for tool and service access.

javascript
const metricsVault = await client.beta.vaults.create({
    display_name: "Metrics CLI",
    metadata: {
        "sandbox0.managed_agents.role": "credential",
    },
});

await client.beta.vaults.credentials.create(metricsVault.id, {
    display_name: "Metrics API token",
    auth: {
        type: "environment_variable",
        secret_name: "METRICS_API_TOKEN",
        secret_value: process.env.METRICS_API_TOKEN,
        networking: {
            type: "limited",
            allowed_hosts: ["metrics.internal.example.com"],
        },
    },
});

The agent runtime sees METRICS_API_TOKEN as a placeholder. The real token is stored as a sensitive vault value and is not returned in API responses. Active credentials in the same vault cannot reuse the same secret_name; to change the key name, archive the old credential and create a new one.

Why The Two Features Fit Together#

Scheduled deployments make agents autonomous.

Vault-backed environment variables make autonomous agents useful with real tools.

That combination is important because scheduled work usually needs credentials. A daily digest needs a database, metrics service, spreadsheet, issue tracker, or source control system. A weekly compliance scan needs package registries, code hosts, internal APIs, and reporting destinations. A recurring browser validation agent needs browser infrastructure credentials.

Running that work without a credential boundary is risky. Storing every key in the sandbox is convenient until a generated command prints it, a package script reads it, or the agent sends it to an unexpected destination.

The safer shape is:

  • the deployment defines when the work should run
  • the session records what happened
  • the sandbox executes the work
  • the vault stores secrets
  • the egress layer decides where secrets can be used

That is the managed-agents backend doing platform work, not application code reinventing scheduling and secret injection for every agent.

What This Enables#

The strongest use cases are not vague "24/7 agents." They are recurring workflows with clear inputs, bounded authority, and inspectable outputs.

Good fits include:

  • weekday status digests from metrics or issue trackers
  • recurring repository maintenance reports
  • daily data quality checks
  • scheduled browser-skill validation
  • dependency or security scans that produce a review artifact
  • periodic customer-account research
  • scheduled report generation from spreadsheets or databases

Weak fits include:

  • unbounded agents with broad network access
  • tasks that need a human approval every few minutes
  • workflows where the credential must be readable by the agent
  • external resident runtimes that do not run inside the Sandbox0-managed sandbox boundary

The last point is intentional. Vault-backed environment variables rely on Sandbox0's sandbox environment and egress credential path. Sandbox0 rejects environment_variable vault credentials for external resident managed-agent runtimes today instead of pretending the same security property exists everywhere.

The Runtime Boundary#

Scheduled deployments and vault-backed env vars make the most sense when the runtime boundary is explicit.

In Sandbox0 Managed Agents:

  • session truth is outside the sandbox
  • deployment truth is outside the sandbox
  • workspace state can live in Sandbox0 volumes
  • compute can be claimed, resumed, replaced, or cleaned up
  • LLM credentials remain in the LLM vault path
  • service credentials can be injected through vault-backed env placeholders
  • network policy is part of the agent runtime, not an afterthought

This is the same infrastructure thesis behind Managed Agents Are Serverless for AI Agents: agent developers should own product behavior, not rebuild the control plane around every model call.

Scheduled deployments move recurring triggers into that control plane. Vault-backed environment variables move service credentials into the same boundary as network policy.

Together, they turn managed agents from "a hosted tool loop" into something closer to a real runtime backend for recurring, credentialed, stateful agent work.

Further Reading#