How do I revoke an AI agent's API access?

The right answer is that each agent should have its own isolated credentials — not shared keys. With isolated credentials, revoking one agent means deleting or disabling one key, with zero impact on other agents or your primary account. With shared keys, revocation is destructive and requires coordinated rotation across everything using that key.

What happens when I revoke an agent's access mid-task?

The agent's next API call returns a 401 or 402 (depending on the infrastructure). If your agent handles errors gracefully, it should surface this as a failure and stop. If it doesn't have error handling, calls will fail silently or throw. Always implement error handling before deploying agents with real credentials.

How do I rotate credentials for a compromised agent without downtime?

With isolated per-agent credentials: create a new agent account, update the agent's configuration to use the new key, verify it works, then revoke the old key. Zero downtime. With shared keys, you're doing a coordinated rotation across your entire system — much harder to do safely.

How long should I keep a revoked agent's transaction history?

Keep it as long as your data retention policy requires — typically 7 years for financial records in regulated industries, 90 days for operational logs. The transaction history is your audit trail for what the agent did before revocation. Don't delete it when you revoke access.

What's the difference between pausing and revoking agent access?

Pausing (or rate-limiting to zero) preserves the agent account and its history while stopping new calls. Revoking (deleting the credential or account) is permanent. Pause first when you're investigating an incident; revoke when you've confirmed the agent should be permanently retired.

How to Revoke Agent Access Without Breaking Your Pipeline

A misbehaving agent needs to be stopped. A compromised credential needs to be rotated. A retired agent needs to be cleaned up. None of these should require taking down your production pipeline.

Most teams discover they can’t do this cleanly because they gave all their agents the same API key.

The Shared Key Problem

If your agents share your primary API key, revoking access for one agent means revoking it for all of them. You either kill the compromised agent and break everything else, or you leave it running and accept the exposure.

That’s not a tradeoff — it’s a design failure. The right architecture doesn’t put you in that position.

The Right Architecture: Isolated Credentials

Every agent that takes production actions should have its own credential — not a shared key. When that agent needs to be stopped, you revoke one credential, and nothing else breaks.

This is table stakes for any serious deployment. It’s also the default design in ATXP: each agent account has its own API key, and revoking the account doesn’t affect your primary credentials or other agent accounts.

Revocation Patterns

Pattern 1: Immediate Shutdown (Emergency)

When an agent is actively causing damage and needs to stop right now:

# Disable the agent account via API
curl -X PATCH https://api.atxp.ai/v1/agents/{agent-id} \
  -H "Authorization: Bearer $ATXP_API_KEY" \
  -d '{"status": "disabled"}'

This makes all subsequent calls using that agent’s key return a 402. Active calls in flight complete; no new calls are accepted. Your other agents and primary account: unaffected.

If you’re on a different system with shared keys, you have two options: revoke the shared key immediately (breaks everything) or remove the agent from your infrastructure manually and rotate the shared key in a planned maintenance window.

Pattern 2: Credential Rotation (Security Event)

When a credential may have been exposed but you’re not sure the agent is misbehaving:

# 1. Create a new agent account
NEW=$(curl -s -X POST https://api.atxp.ai/v1/agents \
  -H "Authorization: Bearer $ATXP_API_KEY" \
  -d '{"name": "research-agent-v2", "budget": 10.00}')

NEW_KEY=$(echo $NEW | jq -r '.api_key')
NEW_ID=$(echo $NEW | jq -r '.id')

# 2. Update your agent to use the new key
# (deploy config change to agent — specific to your stack)

# 3. Verify the new key is working
# (run a test call or check your monitoring)

# 4. Revoke the old credential
curl -X DELETE https://api.atxp.ai/v1/agents/{old-agent-id} \
  -H "Authorization: Bearer $ATXP_API_KEY"

This rotation has zero downtime. The old credential and new credential can coexist during the transition window — no coordinated cutover required.

Pattern 3: Planned Retirement

When an agent workflow is being deprecated:

# Archive (preserves history, prevents new calls)
curl -X PATCH https://api.atxp.ai/v1/agents/{agent-id} \
  -H "Authorization: Bearer $ATXP_API_KEY" \
  -d '{"status": "archived"}'

# Or full deletion (removes account, transaction history remains queryable for 90 days)
curl -X DELETE https://api.atxp.ai/v1/agents/{agent-id} \
  -H "Authorization: Bearer $ATXP_API_KEY"

Archive is preferable to deletion when you need the transaction history for billing reconciliation or audits.

What Good Agent Error Handling Looks Like

After revocation, your agent will eventually try to make a call and get back a 401 or 402. How it handles that matters:

# Python example
try:
    response = await agent.run(task)
except AuthenticationError:
    # Credential was revoked — alert and stop
    await alert_ops_team(f"Agent {agent_id} credential revoked or invalid")
    raise
except BudgetExhaustedError:
    # Balance hit zero — different from revocation
    await request_budget_refill(agent_id)
    raise

The key distinction: a 401 (invalid credential) and a 402 (insufficient funds) require different responses. Don’t conflate them in your error handling.

The Audit Trail

When you revoke an agent, don’t delete its history. The transaction log is the evidence of what the agent did and what it cost. In any post-incident review, you need:

What calls did it make?
How much did it spend?
What time did the anomalous behavior start?

ATXP’s transaction logs are retained independently of the agent account status. Archive or delete the account; the history remains queryable.

The Underlying Principle

Revocation should be surgical. One agent, one credential, one action. If your current setup can’t do that, fixing the credential architecture is higher priority than any feature you’re building.

For more on isolating agent credentials and blast radius: agent credential blast radius.

ATXP agent accounts have isolated credentials by design — revoke one without touching anything else.