Set an AI agent’s ActionDock API key to expire soon enough for your team to replace it deliberately, then update the agent host and verify the new key before the old one expires. In the ActionDock dashboard, Key lifetime offers 1 hour, 1 day, 7 days, 30 days, 90 days, or never. Expiration is not automatic rotation: ActionDock will not renew the key or update the agent’s secret store for you.
This guide concerns the key an agent uses to authenticate to ActionDock over HTTP or remote MCP. It is separate from the provider credential stored in an API connection. If you are trying to keep a target-system token out of model context, see how to give AI agents API access without exposing API keys.
For the current product settings and API limits, see the ActionDock agent documentation for key expiration.
What expiration changes
The key lifetime starts when the owner creates the key. ActionDock returns the full token once and stores a hash; save the token in the agent host’s secret manager when it is shown. The owner dashboard displays the chosen expiration as an exact UTC timestamp.
At or after that time, new HTTP and remote MCP requests authenticated with the key receive 401 Unauthorized. Existing workspace API keys, including primary signup or bootstrap keys, remain indefinite unless separately replaced or revoked. An expired key remains visible in the owner list for review; the owner can revoke it.
Expiration limits how long that particular key can authenticate. It does not reduce the key’s permissions before expiry, and it does not automatically renew, rotate, or revoke a key that has been exposed. If compromise is suspected, revoke the key promptly instead of waiting for its scheduled expiration.
Choose a lifetime that fits the workload
Pick a lifetime based on how long the agent needs unattended access and how reliably someone can replace its secret. The dashboard presets are convenient intervals, not a security rating or a recommendation that every workload use the shortest value.
| Dashboard choice | Practical fit to consider |
|---|---|
| 1 hour or 1 day | A short task, temporary test, or supervised setup where an owner is available to issue a replacement |
| 7 days | A time-bounded rollout or short-lived worker with a regular maintenance owner |
| 30 or 90 days | A longer-running agent when the team can track the date and complete a planned replacement ahead of it |
| Never | A deliberate indefinite key that the owner will manage through monitoring and revocation |
These are operational examples, not additional ActionDock modes. The server also accepts an owner-session or admin issuance timestamp up to 365 days after creation; the dashboard itself offers the choices above. In all cases, expiry is fixed at creation. It is not extended by using the key.
The OWASP Secrets Management Cheat Sheet recommends defined expiration where possible and says credential lifetime should fit the secret’s purpose. It separately treats rotation, revocation, and expiration as lifecycle operations. Use an expiration date alongside a response plan, not as a substitute for revocation or monitoring.
Replace a key before it expires
Plan the handoff while the current key still works. A low-risk rotation can follow this sequence:
- Record the owner and agent that use the current key. Give each key a clear agent or environment name so the owner can identify it later.
- Create a replacement key. In API keys, choose Create API key, enter a name, and select the new key’s lifetime. Keep the old key available during the handoff if it is still valid.
- Save the one-time token securely. Put it directly into the agent host’s secret manager. Do not add it to a prompt, source file, workflow log, or ticket. The dashboard cannot reveal the full token again.
- Update the agent configuration and verify a harmless authenticated read. Confirm the running host is using the new value before retiring the old one.
- Revoke the old key after every intended host has switched. Revocation blocks new authentication with that key immediately. It does not affect the replacement key.
- Track the replacement’s UTC expiration. Arrange your team’s reminder or rotation process outside ActionDock, because expiring keys are not renewed automatically.
Creating a separate key for each agent or environment makes the owner list easier to understand and lets you replace one caller at a time. ActionDock authenticates these workspace keys; they do not change the credentials or permissions configured for downstream provider connections.
If the key has already expired
An expired key cannot extend itself. A signed-in workspace owner can create a replacement from API keys. An administrator can also issue a key through the admin API when that route is part of the workspace’s operations. Save the new token in the correct host, then verify authentication and inspect the agent’s current job state before resuming work.
An HTTP 401 response means the request was not applied for lack of valid authentication credentials under RFC 9110. However, do not turn an authentication recovery into a new write automatically. An earlier request may already have returned a durable ActionDock job before a different host or later step encountered an expired key. Preserve the existing job ID and idempotency key; inspect that job instead of inventing a new write and key. If the original outcome is ambiguous, follow the reconciliation and retry guidance.
Expiry does not cancel requests that were already authenticated or ActionDock jobs that were already accepted. A queued write still follows its normal owner-approval and execution rules. The key deadline also does not expire a dashboard session or the provider credential configured on a connection.
Expiration, revocation, and leaked-key detection are different
- Expiration stops future authentication with one key at its stored deadline.
- Revocation disables a key now, for example after a suspected leak or when an agent is retired.
- Leak detection looks for exposed secrets and may help an owner respond; it does not itself prove a credential was revoked.
Recent token news also shows why the issuer matters. GitHub’s expiring GitHub CLI credentials are opt-in and automatically refreshed by gh when the server supports refreshable credentials. A token copied from gh into another tool can still expire without being refreshed there. ActionDock workspace keys do not auto-refresh: the owner must create a replacement and update the agent host. GitHub’s separate public monitoring for exposed secrets can help eligible Enterprise teams discover certain public leaks, but detection is not revocation and does not change an ActionDock key’s deadline.
Know which access paths expiration covers
ActionDock applies this expiry to workspace keys presented to its HTTP API and remote MCP endpoint. It does not revoke dashboard sessions, alter provider credentials, or expire credentials used by local stdio configuration. Those have separate owners and lifecycle controls. An agent with a direct provider token, authenticated browser session, or alternate MCP connection can also bypass ActionDock’s key boundary.
Expiration is a useful way to bound one workspace key’s lifetime, provided the receiving host can be updated on time. Pair it with separate keys for separate agents, secure storage, a clear owner, and an immediate revocation procedure for suspected exposure. The MCP server security guide explains why transport authentication and authorization for downstream writes are separate decisions.