AI-native
How long should an AI agent's API keys last?
As long as the job, and no longer. A key for one task should expire in minutes to a couple of hours, a key for one agent run in about a day, and no agent should hold a long-lived account key. Every agent credential leaks eventually, into a log, a prompt or a file it wrote, and the expiry decides how long that leak matters.
Updated November 5, 2026
Why do agent keys need short lives?
Agents copy text around far more than people do. A key passed to an agent can end up in a tool result, a transcript, a commit or an error message. You can't promise it never leaks, so limit what a leak is worth: give the key only the access the job needs, and make it stop working soon after the job ends. Sandboxer's guide on how long an agent's API key should stay valid makes the same argument and tests each case.
What lifetime fits which job?
Sandboxer's guide gives a policy you can copy:
| Who holds it | Lifetime | Scope |
|---|---|---|
| One task: a tool call, a test run, a CI step | 15 minutes to 2 hours | One sandbox, only the actions the task uses |
| One agent run, or one working day | 8 hours to 1 day | The ci preset, which can delete only the sandboxes it created |
| Your orchestrator on a server you control | Up to 90 days, rotated | The narrowest preset that works |
| An admin or full-access key | Keep it out of agents | Use it only to mint the keys above |
Sandboxer's default key lifetime is 90 days and the maximum is 365, which the guide calls too long for anything an agent holds, so always set one:
sbx api-key create task-key --ttl 2m --sandbox <sandbox-id> --actions sandbox.read,execAfter the expiry, calls fail with 403 api_key_expired; a key revoked earlier fails with 401.
What about code running inside a sandbox?
Don't give it your account key. If it needs Sandboxer access, give it a scoped key with a short --ttl. If the agent needs to use a third-party API key without being able to read it, Sandboxer's guide on keeping API keys out of an agent's sandbox runs a small proxy outside the VM that adds the key to each request, and gives the agent only a proxy token you can revoke.
Do signed-in AI apps count as keys?
Yes, and they are the easiest to forget. An AI app that signs in to Sandboxer's MCP server gets full access to the account through MCP until you disconnect it under API keys. If a client should have less, or should expire on its own, give it a scoped key with an expiry instead of signing in. On Transformer, a sign-in or workspace key acts for exactly one brand or creator workspace and can be revoked in Settings → Agents or on the workspace page.
How does Flagger.gg handle agent token lifetimes?
Flagger.gg builds the limit in: an agent token covers one project, a list of environments and specific actions, lasts 90 days at most, is stored as a hash and can be revoked at any time. Agents also can't approve, so even a leaked token can't push a change past an approval a team requires. See Flagger.gg's guide to scoped agent tokens.
What should you do when a job ends early or a key leaks?
Revoke it, or rotate it if something else still needs one. On Sandboxer, sbx api-key rotate issues a new secret and stops the old one at once, and sbx api-key revoke stops a key while its sandboxes keep running, so stop those too. For the full order of operations, see how to stop an AI agent that's going wrong.
Frequently asked questions
Should an AI agent ever have an admin API key?
No. Keep admin and full-access keys for minting narrower keys, and give each agent a scoped key that expires.
What is a good expiry for a CI key?
For a key a pipeline stores, up to 90 days with regular rotation. For a key created for one CI step, minutes to a couple of hours.
How long do Flagger.gg agent tokens last?
90 days at most. They can be revoked at any time.
Does an expired key stop sandboxes it created?
No. Expiry and revocation stop new calls with that key. Stop or delete its sandboxes separately.