How to revoke an AI agent's access instantly

Six ways to cut an agent off on Naïve: interrupt or cancel the session, delete the vault credential, revoke the connection, revoke the API key, deny the tool. Why network-boundary injection makes each one instant.

Revoking an agent's access means every further action is denied, now, without redeploying anything or rotating a key you share with the rest of production. Earlier versions of this guide described one suspend call on a bundled object; that model is gone. An agent on Naïve is a model, a prompt, tools, skills, a budget and a harness; the things it can reach are held separately, in a session, a vault, a connection, an API key and a policy. Each has its own off switch, and the right revocation is usually the narrowest one that ends the risk.

This guide walks the ladder from narrowest to widest, then explains why every rung takes effect immediately. If you need a pause rather than a stop, read how to add human approval to an AI agent instead.

The revocation ladder

Most incidents need one rung. A runaway loop is a session problem. A leaked token is a vault or key problem. A departing customer is a connection problem. Reaching for the widest cut first turns one misbehaving run into an outage for every agent in the organization.

Stop the run: interrupt, steer, cancel

A session is one metered, resumable run of an agent. Three operations control it, documented under session operations.

Interrupt stops the current turn at the next commit boundary. You lose at most one turn, never the run. The session lands at idle with stop_reason: "interrupted", its history and sandbox preserved, and the interruption is written to the audit log as session.interrupted.

vetta session interrupt --session $SID

Steer is an interrupt and a new message in one call. The agent wraps up the current turn cleanly and then follows the redirect: the right move when the agent is doing the wrong thing rather than an unauthorized thing.

vetta session send --session $SID --interrupt --message "Stop. Issue a store credit instead."

Cancel is the terminal operation. The in-flight turn stops, the sandbox is released, and the session moves to cancelled. The record and its events are permanent; files the session produced go with the sandbox, while anything promoted with publish_file or uploaded to the Files API survives. There is no archive and no delete route; cancel is the only terminal operation.

import { randomUUID } from "node:crypto";
import { createClient } from "@usenaive-sdk/vetta";
 
const client = createClient({
  baseUrl: "https://api.vetta.sh",
  apiKey: process.env.VETTA_API_KEY!,
  fetch: globalThis.fetch,
  idempotencyKey: () => randomUUID(),
});
 
await client.sessions.interrupt(sessionId);          // stop the turn, keep the run
await client.sessions.cancel(sessionId);             // terminal

A session stop does not touch the credentials the agent was using. If a secret may be compromised, keep climbing.

Cut the credential: the vault

The vault is where an agent's secrets live, and its defining property is that the agent never sees them. A credential is sealed once and referenced by ID. Reads return metadata only; there is no reveal route and the schema has no value field. The design is in introducing Vault.

Revoking a secret is therefore a delete. List the vault's credentials to find the ID, then remove it:

vetta vault credentials --vault vlt_...
vetta vault rm --vault vlt_... --credential vcr_...

There is no update command on purpose. Rotation is set a new credential, then rm the old one, so last_injected_at stays attributable to exactly one secret. During an incident, "when was this value last used?" is the first question, and an in-place update would make it unanswerable.

printf '%s' "$NEW_KEY" | vetta vault set --vault vlt_... --env PAYMENTS_API_KEY --host api.payments.example.com
vetta vault rm --vault vlt_... --credential vcr_old...

If the whole vault has to go, vetta vault delete <vault-id> soft-deletes the container and destroys its secrets for good. In the SDK: client.vaults.credentials.delete(vaultId, credentialId) and client.vaults.delete(id); see the vaults reference.

Cut one MCP integration

MCP servers are declared on the agent by name and URL, and their auth is never on the agent definition. A static_bearer or mcp_oauth credential in the vault is matched to the server by URL and injected server-side when the agent connects. The sandbox never receives the token, which is why there is no separately revocable "MCP session" any more: there is no token in the agent's hands to revoke.

To cut one integration without touching the rest, delete that server's vault credential. An auth failure surfaces as a session.error event naming the server; the agent's other tools keep working. Or remove the tools themselves in the agent's tool configs, where every MCP tool is keyed <server>.<tool> and can be set to enabled: false or permission: "deny". The default permission for MCP tools is ask, so a newly exposed server tool never auto-runs. See the MCP connector docs.

Naïve also publishes its own API as an MCP tool catalog at POST /v1/mcp. Every tool call is re-dispatched as an ordinary API call carrying the caller's own bearer, so a tool can never reach further than the key that invoked it, and revoking that key revokes that client. Routes that mint or accept secrets are withheld from the catalog entirely. See the MCP server reference.

Revoke a connection

A connection is an authorized account in a third-party app, bound to one identity. The agent never handles the raw credential; we store it, inject it at call time, and refresh managed OAuth tokens server-side.

Revoking it is one call, client.connections.disconnect(id) in the SDK. The provider drops the stored credential, the account moves to disconnected, and every later call through it is refused.

vetta identity disconnect --connection ca_...

Two related cuts: deleting the org-level auth config means connections already minted against it stop refreshing. And vetta identity detach revokes an agent's grant to a persona: the identity is untouched and running sessions are not interrupted, but the next session cannot select it. The full route list is in the connections API.

Revoke or rotate an API key

Keys are organization-scoped and carry explicit scopes, so a CI key or a sandbox credential need not be an admin key. Revocation is immediate: in-flight requests holding the old secret start failing with 401. Rotation mints a replacement secret under the same ID and invalidates the old one.

vetta keys revoke key_...
vetta keys rotate key_...

In the SDK these are client.keys.revoke(id) and client.keys.rotate(id); only rotate answers a new secret, once. Both land in the audit log as api_key.revoked and api_key.rotated. vetta keys list shows last_used_at, which makes stale keys easy to find before they become the incident. Reference: vetta keys and authentication.

Deny at the policy layer

Every capability an agent has flows through one place, the tool call, and policies are checked there before a tool runs. Each tool resolves to allow, ask, or deny. A deny means the tool is not offered to the model at all. Connections run under the same filter: connections.mode: "allowlist" keeps a new connector type unreachable until you add it, and an attempt outside the list is refused with a typed forbidden error before any external request is made.

vetta agent update ops --file ops.json

The thing to know about policy as a revocation tool is versioning. An update mints a new immutable agent version, and every session pins the version it started on. A deny protects every session created from then on, but it does not reach into a run already going. For that, interrupt or cancel first, then let the next session pick up the new version.

Why the boundary makes revocation instant

Every rung above takes effect immediately for one structural reason: the agent never held the thing you are revoking.

A vault value is substituted outside the sandbox, at the network boundary, and only when the request is bound for the credential's destination. Inside the sandbox, in the model's context, in the transcript and in your logs, there is only a placeholder. Delete the credential and the placeholder is inert; there is no cached copy to expire because there was never a copy. The same holds for a connection token, injected at call time, and for MCP auth, injected server-side at connect. Revocation never chases a secret through the agent's memory; it changes one row in a store the agent cannot read.

Policy works the same way. Enforcement is at the tool-call boundary rather than inside a prompt, so a policy holds regardless of what the model decides to attempt. The env_var kind extends the boundary rule to general sandbox egress, substituting only for the bound host, so a prompt-injected agent that sends the placeholder elsewhere sends the placeholder, not the secret. That kind is coming soon and refused today.

Verify the cut

• After an interrupt, vetta session get $SID shows idle and stop_reason: "interrupted". After a cancel, cancelled.
• After a credential delete, vetta vault credentials --vault vlt_... no longer lists it.
• After a disconnect, vetta identity connections show ca_... reads disconnected; that read reconciles against the provider.
• After a key revoke, any request with the old secret is 401, and GET /v1/audit_logs carries api_key.revoked with the acting principal.
• After a policy change, a new session of the agent does not see the denied tool, and any blocked call is recorded as policy.denied.

Wire it in before you need it

Revocation under pressure is only reliable if the one-liner already exists. Put the right rung in the right place: a session cancel behind the stop button in your admin UI, a connection disconnect in your offboarding flow, a vault rotation on a schedule, a key revoke in your incident runbook. Each is one command or one SDK call, scoped to exactly what needs to stop.