Your AI Agent Restarted. Did Its Credentials Survive Too?

A restart test that checks only whether the process comes back is incomplete. For an AI agent, the more dangerous question is whether credentials, browser profiles, cached tokens, and queued work come back with the same authority.

A useful deployment test treats restart as a security boundary:

• durable state should survive only when you explicitly intend it
• disposable execution state should disappear
• credentials should be scoped to the smallest useful identity
• recovery should not replay a side effect just because a token survived

This post shows a small test plan you can run against an agent runtime, OpenClaw deployment, or browser automation worker.

Start with a state and identity inventory

Before changing configuration, write down what exists on disk and what exists outside the process:

Item	Expected after restart	Risk if copied blindly
task state and checkpoints	durable	stale work can be replayed
OAuth refresh token	durable only if required	token theft extends beyond one run
browser profile	usually disposable or isolated	cookies cross tasks and tenants
/tmp downloads	disposable	secrets and private files linger
queue/outbox	durable with idempotency keys	duplicate external actions
provider session cache	explicit expiry	hidden credential persistence
logs and traces	durable, redacted	secrets leak into backups

Do not group these into one volume just because the runtime makes that convenient. A restart should make the persistence policy visible.

Separate authority from continuity

An agent may need to remember a task without retaining the ability to act as the previous worker. Model those as separate records.

A minimal checkpoint can contain:

task_id, step_id, input_hash, output_hash, side_effect_key, state, created_at, expires_at

The checkpoint answers “where was the workflow?” It should not contain a reusable access token. Store the token in a separate secret store or short-lived credential mount, and record only a credential reference plus its expiry.

For every resumed step, re-check:

1. the current tenant and task owner
2. the current policy version
3. whether the credential reference is still valid
4. whether the side-effect key already has a terminal result
5. whether the destination is still allowed

A restored checkpoint is an input to authorization, not an authorization decision.

Test the blast radius with disposable fixtures

Create two identities and two workspaces. Give each identity a different marker resource, such as agent-a-marker and agent-b-marker. Then run the same recovery sequence:

# Pseudocode: run in an isolated test environment
agent start --workspace tenant-a --credential cred-a
agent checkpoint --after plan --before tool-call
agent stop --kill

# Rotate or revoke the old credential before recovery
secrets revoke cred-a
agent restore --workspace tenant-a --checkpoint latest
agent resume --step tool-call

The expected result is not merely “the process is healthy.” The resumed call must be rejected or re-authorized with a replacement credential. It must never reach tenant B, use an old browser cookie, or silently fall back to a host-level credential.

Add these fixtures to the test matrix:

• credential revoked between checkpoint and resume
• credential rotated but reference unchanged
• workspace path restored under a different tenant
• browser profile copied into a new worker
• environment variable inherited by a child process
• backup restored to a machine with a broader IAM role
• queued mutation present when the worker crashes after sending
• clock moved past the credential or lease expiry
• policy changed after planning but before execution

Record ALLOW, DENY, or UNKNOWN for each case. UNKNOWN is important: a timeout after a remote side effect is not proof that nothing happened.

Make recovery idempotent

Persist an intent record before dispatching a mutation. Include a stable request key and a fingerprint of the normalized arguments:

{
  "request_key": "task-42:step-7:send-email:v3",
  "destination": "mail-service",
  "arguments_sha256": "...",
  "credential_ref": "cred-a",
  "policy_version": "2026-08-09T01:00Z",
  "state": "NOT_SENT"
}

Only transition to SENT or SUCCEEDED after evidence supports that transition. If the worker dies after dispatch and before the response, mark the result UNKNOWN and reconcile with the provider using the request key. Do not blindly retry with whichever credential happens to be mounted after restart.

This same rule applies to browser actions. A surviving cookie can make a second click look successful while performing a second purchase, submission, or deletion. Prefer provider-side idempotency where available; otherwise use a durable action ledger and a post-restart reconciliation step.

Check backup and restore, not just restart

A backup can widen the blast radius if it contains more authority than the running worker needs. Verify that:

• tokens are encrypted and excluded from ordinary application exports
• restored secrets require a new, scoped grant
• logs and browser profiles are redacted or isolated
• a tenant-A backup cannot be mounted into tenant B
• restore tooling does not run with the production agent role
• expired credentials remain expired after restore

For an always-on deployment, the hosting environment is part of this boundary. If you use managed OpenClaw hosting on Ampere, keep the same separation: durable task state, secret storage, browser profiles, and temporary execution should have different retention and access policies. The hosting layer does not replace those tests.

A 10-minute acceptance drill

1. Start a worker with a test-only credential and create a checkpoint before a mutation.
2. Kill the worker and revoke the credential.
3. Restore the checkpoint on a fresh execution surface.
4. Confirm the old credential cannot authenticate and no cross-tenant marker is visible.
5. Force an after-send timeout and verify the result becomes UNKNOWN, not an automatic retry.
6. Restore a backup and confirm expiry, tenant, and policy checks still apply.
7. Inspect the audit record for task ID, request key, credential reference, policy version, and final outcome.

A deployment is not restart-safe just because the process returns to RUNNING. It is restart-safe when continuity is preserved without silently preserving authority, and when ambiguous external effects are reconciled instead of repeated.

If this kind of operational detail is useful, follow for practical tests around agent runtimes, deployment, recovery, and security.