How Long Should an AI Agent's API Key Stay Valid?

Short answer: Match the key to the job: minutes to a few hours for one task, one run or one day for an agent, and never a long-lived account key. Set the expiry at creation with sbx api-key create --ttl, which accepts minutes. Once it passes, calls fail with 403 api_key_expired; revoke earlier and they fail with 401.

An agent's credential will leak sooner or later: into a log, a prompt, a tool result or a file the agent wrote. Its expiry decides how long that leak matters. This page shows what each Sandboxer credential does when its time runs out, tested on prod on 2026-11-04, and gives a policy you can copy.

The policy#

The default TTL is 90d and the maximum is 365d. Both are too long for anything an agent holds, so always pass --ttl.

A task key that expires in two minutes#

--ttl takes days (7d), hours (8h) or minutes (2m). This key can read and run commands in one sandbox and nothing else. The secret goes into a shell variable and is never printed:

Created at 11:03:22 UTC, it expires at 11:05:22. Give it to the task through the environment, not a command-line argument:

Inside its window the key still can't leave its scope. Reading the account needs account.read, which it doesn't have:

curl -H @- reads the header from standard input, so the key never appears in the process list. Listing sandboxes with this key returned one sandbox, its own.

After the expiry#

We waited 125 seconds and tried the same calls at 11:05:28:

The first call after the deadline failed. Nothing had to run on our side to make that happen.

A per-run key, revoked at the end#

For a whole agent run, use the ci preset with a TTL that covers the run, and revoke the key when the run ends rather than waiting for the deadline:

sbx api-key list shows every key's expiry. Filtered to our two test keys:

Two things to notice. expiringSoon is true for any key with less than 14 days left, so every short-lived agent key carries it. And an expired key stays in the list until you revoke it. Revoke by id, then try the key:

Revoked is 401 unauthorized; expired is 403 api_key_expired. Your agent's error handling can tell the two apart: an expired key means "ask for a new key", a revoked one means "stop". Revoked keys drop out of sbx api-key list, but sbx api-key usage <id> still answers. For the revoked task key it returned {"requests":5,"windowDays":30}.

Creating keys needs a browser session or an admin key. Keep that key with the orchestrator that mints the per-run keys, never in the agent. A TTL above the maximum is refused before anything is created:

The token inside every sandbox#

Each sandbox gets its own key in SANDBOXER_TOKEN, limited to that sandbox. The API keys docs list no separate expiry for it: you don't set a TTL, it belongs to the sandbox. We ran a probe of REST calls with it from inside two small sandboxes, one on the account's default environment and one created with --no-env. The probe used the token without printing it:

This matches the docs: the default token can run commands, read and write files and host ports in its own sandbox, but can't create, fork or delete sandboxes or save snapshots. The --no-env token can only read that sandbox and host its ports.

Since the token has no TTL of its own, plan around the sandbox. A per-task sandbox that you delete when the task ends is the simplest way to keep the token short-lived. Never print SANDBOXER_TOKEN in a command you run through sbx exec, because sbx history keeps exec command output for 90 days (Long-running tasks).