Revoke an agent's access

Revoking access is a decision for people. You do it in the Console, or with the CLI. Your agent can read the facts that you need first, such as which key produced an agent's telemetry and what the audit log recorded.

Ask your agent

"Which API key produced the telemetry of the checkout agent? Show its scopes, its last use and its expiry. Do not revoke anything."

Job	MCP tool or action	CLI command
List keys with their scopes and last use	list_api_keys (read action)	anectico apikey list
Find the key behind an agent	resolve_agent_asset_attribution (read action)	anectico asset attribution
Narrow a key's scopes	update_api_key (write action)	anectico apikey update
Revoke a key	revoke_api_key (write action)	anectico apikey revoke
Read the audit trail of a key	list_audit_events (read action)	anectico audit list

Reads need mcp:read with api_key:read (keys), agents:read (attribution) or audit:read (audit). Changing or revoking a key needs mcp:write, api_key:read and api_key:write, and shows a preview first. A revocation has no proof page. Check it as described in 3. Verify that access stopped.

An agent cannot revoke an approval. A signed-in person does that, in the Console or with the CLI, as described next.

Revoke an OAuth approval

In the Console, open Agents and keys (/agents). Under Connected agents, find the approval by client, host, workspace, permissions, and last use; select Revoke and confirm Revoke access. An administrator with members:write can use Everyone's connections to revoke another person's approval in the current workspace. See The Console.

Or use your human CLI login:

anectico auth connections list --json
anectico auth connections revoke <id> --yes

Add --org-wide to list or revoke other people's approvals with members:write. API keys and connected agents cannot manage approvals. Unset ANECTICO_API_KEY when using your saved human login. Revocation denies the next MCP request, refresh, and unredeemed codes belonging to that approval. Other approvals stay connected; reconnecting requires fresh consent.

Use these connection controls to stop OAuth access. Anectico does not advertise a token revocation endpoint. Removing the server from a host's configuration does not revoke its approval. A brief refresh retry window never overrides a revoked approval.

Revoke an API key

Revoke a key when that credential must stop working permanently. For a reversible write freeze or a two-principal approval process, use Contain an agent.

1. Identify the credential

In the Console, open Agents and keys (/agents) and look under API keys. Or list keys from an authorized administrative CLI session:

anectico apikey list
anectico apikey list -o json

Check the key ID, name, project, expiry, and last-used time. Use JSON to see the complete scope set; the terminal table shortens that column.

If you only know the agent, ask your agent for its attribution (anectico asset attribution, see See every agent that is running) or call GET /api/v1/assets/{assetId}/attribution. The response's credentials entries identify observed API keys. An empty list means no credential attribution was recorded; it does not prove the agent used none. A bearer_token attribution points to a user session, not an API key.

2. Revoke the key

Requires api_key:read, api_key:write and mcp:write for the CLI server preview and confirmation. In the Console, select Revoke on the key under API keys. From the CLI, check the ID before confirming:

anectico apikey revoke <key-id> --idempotency-key <operation-key>
# Review the complete server preview, then repeat the same arguments:
anectico apikey revoke <key-id> --idempotency-key <operation-key> --confirm-token <server-token>

Revocation is permanent. A replacement requires a new key. Removing an MCP server from a host's configuration does not revoke copies of its secret elsewhere.

If the agent should keep running with less authority, narrow the key instead of revoking it. This replaces the key's complete scope set and keeps the same key string:

anectico apikey update <key-id> --scopes logs:read,traces:read --idempotency-key <operation-key>
# Review the complete server preview, then repeat the same arguments:
anectico apikey update <key-id> --scopes logs:read,traces:read --idempotency-key <operation-key> --confirm-token <server-token>

In MCP the same change is the write action update_api_key with replace_scopes: true. You can only grant scopes you hold yourself, so a scope you remove and do not hold cannot be given back by you. A key under containment cannot be edited until the containment is lifted.

If you also need to stop an existing export job, cancel it before revoking the credential. Revocation blocks access to its output but does not cancel production of that output.

3. Verify that access stopped

Use a separate authorized session to confirm the key is revoked in anectico apikey list (or under API keys in the Console). Requests with the revoked key return 401. That status alone cannot distinguish revoked, expired, malformed, and unknown keys.

Operation	Effect of revocation
New REST, MCP, CLI, or ingest request	Authentication fails on the next request.
Unused confirmation token or cached idempotent result	Unreachable through the revoked credential.
Short request already authenticated	May finish; revocation does not cancel it.
Export download already in progress	Stops within a few seconds.
Live log tail	Stops within about five seconds: the stream re-checks the credential on every five-second heartbeat.
Already commissioned export job	May finish producing the file; the revoked key cannot download it.

For exact client errors, session behavior, and download ownership, see Credential revocation behavior.

4. Review earlier activity

With audit:read, open Audit log (/audit-log) in the Console. Compare mutation records with the agent's receipts and the current resource state. An error or unknown outcome does not prove that nothing changed.

For the key's grant history, use GET /api/v1/account/audit-events?target_api_key_id={id}, the CLI's anectico audit list --target-key {id}, or the MCP read action list_audit_events with target_api_key_id. This filters the key that was changed, not the credential that performed the administration.

The audit has two limits: calls refused before dispatch are not recorded, and a failed audit write does not roll back a mutation. See audit results and grant history.

Revocation cannot retract data already read, delivered notifications, provider tickets, or permanently deleted telemetry. Handle those consequences separately.

Stop an app that reads

An app you host, such as a status board, holds one dedicated management key that only reads. Revoking that key is how you stop it. Which credential each host holds says how the key is made.

In the Console, open Agents and keys and find the app's key by its name. The row shows its project, its expiry, every permission it holds, when it was last used (recorded about once a minute), and its budget, request rate and today's accepted work, or says they are unknown. Calls made with this key lists what it called and Changes to this key opens its grant history in the audit log. Revoke names the key, its id, its project, its expiry and its permissions before you confirm. With the CLI, anectico apikey get <key-id> -o json shows the same facts, and anectico apikey revoke shows the same key and asks for the same confirmation.

Action	What it does to an app that only reads
Revoke the key	Its next request is refused, a read included, and so is every later one. A repeated request, or one that asks whether an answer changed, is refused too: an answer that did not change does not keep the key working.
Freeze (a containment)	Removes write permissions and keeps the read ones. A key that only reads keeps reading. An agent-level kill reaches only keys that declared which agent they belong to, and an app's key normally declares none.
An operation limit or a request rate of zero	Requests answer 429. The key is still valid and you can lift the limit. It is a throttle, not a revocation.
Let it expire	The key is refused on its first use after the expiry.

Revoking does not stop the process that holds the key, retract data the app already read, or undo anything it already caused. The app's caches, exports, logs and messages are yours to keep or delete: Anectico's erasure cannot reach them. If the app should keep running with less authority, narrow its permissions instead. A refused request is not charged to the key's or the workspace's request allowance.

If the secret is lost, revoke that key and create a new one with a new --idempotency-key. Repeating the first creation returns the original key's details and no secret, and never a second key.

Attribution. The record shows that the app's key called Anectico. It cannot say which of the app's own users asked; that record is your backend's.

An app should show that its access ended rather than retry or switch keys. Each worked example does: the status board stops reading and says its access has ended, the bot answers so, and the nightly report exits 4 with the component marked.

Rotate a healthy credential

For routine rotation, create and verify the replacement before revoking the old key:

anectico agent bootstrap --project <project-id> --host claude --scope-profile investigate
anectico agent doctor --host claude
# Verify the replacement works, then:
anectico apikey revoke <old-key-id> --idempotency-key <operation-key>
# Review the complete server preview, then repeat the same arguments:
anectico apikey revoke <old-key-id> --idempotency-key <operation-key> --confirm-token <server-token>

Bootstrap replaces the stored secret and the host's anectico entry while preserving other MCP entries. Keep separate keys for local development, CI, and operations; set an expiry for each.

Related controls

• Contain an agent: request and approve a freeze, revocation, or kill. In the Console, this is Agent safety (/agent-safety).
• Withdraw a delegation: records withdrawn authority and flags later use, but does not itself stop the credential.
• Scope recipes: prevent excess authority when minting the replacement.

A URL profile only narrows that connection. The caller can remove it, so it is not a substitute for revoking or narrowing the key.

Agent budgets

An owner or admin can also edit a connection’s work limits and see today’s accepted usage on Connected agents. Tightened limits apply within six seconds without new consent. See Manage agent budgets.

Browser aggregate sharing

Review a grant on Agents and keys, or use app-view grant revoke with its exact project and version and server confirmation. This stops one share; parent-key revoke stops all descendants, including the next conditional read. Freeze does not promise to stop reads. Data already displayed or copied remains outside revocation's reach. Unknown viewer usage is never measured zero.

See Share a saved aggregate with a browser page for the full credential, theft, lifetime, privacy and external-copy contract.

Stop a public static aggregate

In Agents, review and revoke the selected publishable app-view grant, or revoke its parent key to stop all descendants. The next read, including an unchanged ETag, refuses. The page needs no backend or platform renewer. A copied public credential grants only its approved aggregate until current access ends; data already displayed or downloaded cannot be recalled. Your own copies remain subject to your retention and disposal policy.