What to Do When Secrets Leak into an AI Agent: Access Revocation, Auditing, and Returning to Work

Instructions verified against documentation on September 16, 2026.

When an autonomous agent runs commands like git diff, reads local configuration files, or accidentally includes environment variable dumps directly in model prompts, secrets leave the trusted perimeter. In this situation, you must halt background scripts, block compromised credentials, audit logs with an awareness of their limitations, and restart the environment following the principle of least privilege.

Distinguishing Normal Configuration from Context Leaks

Before initiating incident response, it is crucial to distinguish between normal API usage and an actual compromise.

Normal operation involves passing an API key exclusively in the authorization fields of the intended model provider (for instance, via OPENAI_API_KEY or ANTHROPIC_API_KEY variables) to authenticate tool requests to the language model. Variables such as ANTHROPIC_BASE_URL or OPENAI_BASE_URL specify network endpoint addresses (endpoint/base URL), not secrets or authentication tokens.

A model leak is defined as an event where unrelated infrastructure secrets—such as GitLab personal access tokens, long-term AWS IAM keys, private SSH keys, database credentials, or corporate network tokens—enter the user prompt, conversational context, attached files, or utility output streams (stdout/stderr) and are transmitted outbound to an external service. While one should not assume that all intermediate proxies or gateways are inherently malicious, transmitting secrets outside an isolated environment requires immediate containment.

Immediate Actions: Stopping Processes and Documenting the Incident

The first priority is preventing further data transmission:

1. Terminate the local agent process and disable associated background tasks (cron jobs, CI/CD automation scripts).
2. Record incident metadata in a local report without duplicating the secret itself: type of compromised credential, approximate timestamp of the first request, task/session identifier, and the recipient network endpoint address.
3. Do not send the exposed secret in plaintext to support chat channels or in follow-up queries to neural networks for verification.

All key revocation and replacement operations must be performed exclusively from a trusted workstation using official provider management consoles.

Revoking Access by Service Type

Different platforms implement isolation and authorization revocation according to distinct architectural rules.

Model Access Keys (OpenAI API)

In accordance with official OpenAI best practices for API key safety, suspected compromise requires rotating the key and reviewing resource consumption.

When a leak is suspected, the compromised key must be revoked first:

1. Immediately navigate to the OpenAI API key management web interface and revoke (Revoke/Delete) the compromised key. This blocks further unauthorized calls at the cost of controlled temporary downtime for dependent services; revocation should not be delayed pending a full audit or lengthy updates across all consumers.
2. Generate a new key and update service configurations.
3. Open the Usage dashboard and analyze activity within the established exposure window, comparing it against expected operations.

GitLab Personal Access Tokens

According to GitLab documentation on Personal Access Tokens, revoking a personal access token invalidates it immediately:

1. In the GitLab interface, select your avatar in the upper right corner > Edit profile > Access > Personal access tokens.
2. In the active tokens table, locate the compromised token identifier and click Revoke.

The Rotate function in GitLab revokes the old token but preserves the previous scopes. If the compromised token had excessive permissions, it should be revoked completely and replaced with a new token configured with minimal scopes. The token details page displays the last used date and the five most recent unique IP addresses. Note that these metrics update with a system delay.

AWS Access Keys (IAM Access Keys)

The neutralization procedure for IAM keys is governed by the AWS guide on securing access keys and documentation on managing access keys for IAM users:

1. Sign in to the AWS Management Console, navigate to IAM > Users, and open the Security credentials tab.
2. In the Access keys section, locate the identifier of the compromised key and change its status to Deactivate.
3. Once control has been restored, remove the key by selecting Delete.

[!IMPORTANT] Setting a key to Deactivate halts the acceptance of new requests signed with this long-term credential, but does not invalidate previously issued temporary credentials (AWS STS tokens) and does not automatically terminate active sessions. The Revoke active sessions action applies only to sessions of the corresponding IAM role; active IAM Identity Center sessions and other types of STS tokens require separate revocation through their specific authentication mechanisms. A security administrator must also cross-reference API calls using AWS CloudTrail and the get-access-key-last-used operation. Do not run untested, destructive bulk deletion CLI commands during an active incident.

OpenSSH Keys and Authorization

OpenSSH authorization procedures are documented in reference manuals man sshd(8) and sshd_config(5):

1. Administrators must remove the compromised public key from the authorization file on all servers. The file path is determined by the AuthorizedKeysFile directive (by default ~/.ssh/authorized_keys, though infrastructures may configure centralized files or certificate validation via an SSH CA).
2. Before making modifications, ensure an independent backup access path is available (such as a provider web console or out-of-band management) to avoid locking yourself out.
3. Removing the public key prevents new connections from being established, but does not terminate existing active sessions.

The who command displays only users allocated a pseudo-terminal (TTY) and does not provide an exhaustive session inventory: it will not reveal tunnels, port forwardings, or non-interactive commands. Blindly killing the root sshd process is impermissible, as it does not guarantee the termination of child sessions and risks severing administrator access to the server. Administrators must specifically inspect the process tree, active network connections, and authorization logs, terminating individual suspicious sessions. Deleting the private key locally or changing its passphrase has no effect on a key that has already been copied externally.

Tailscale Networks and Corporate VPNs

According to Tailscale documentation on Auth Keys, an authentication key is intended solely for node registration:

1. In the Tailscale console, navigate to Keys and revoke the compromised auth key. This prevents new devices from registering.
2. Revoking an auth key does not disconnect already registered nodes. Administrators must navigate to the Machines tab, review the device inventory, and manually delete (Remove/Delete) any unauthorized machines.

For traditional corporate VPNs (IPsec, OpenVPN, WireGuard, and proprietary solutions), there is no single universal revocation procedure via CRL: the specific mechanism depends on the authorization scheme in use (x509 certificates, static preshared keys, RADIUS/IdP tokens). On many gateways, changing an account password does not immediately terminate an active tunnel. The procedure must be escalated to a network administrator to revoke the certificate/account and forcibly terminate active sessions through the specific VPN gateway management console.

Consequence Analysis: Logs, Time Windows, and Irreversible Risks

When correlating the incident with system logs, account for technical limitations in telemetry:

• Exposure window: establish the exact time interval between the initial transmission of the secret to the agent and the confirmed key revocation and active session termination.
• Log limitations: account for event ingestion delays, log retention periods, and telemetry blind spots (such as lack of detailed parameter auditing in certain APIs, or the absence of logging for non-TTY sessions).
• Absence of evidence principle: the absence of anomalous log entries or zero token usage within the accessible log window does not prove that the secret was not intercepted or stored by a third party for delayed use.

Revoking keys prevents future requests, but does not retrieve data, source code, or environment variables already sent to an external service. Deleting a conversation in an agent or platform web interface hides the transcript, but provides no technical guarantee that the data has been purged from downstream provider logs or caches.

Safe Restart: Mitigating Risks and Verifying Isolation

Returning the agent to operational status must reduce the risk of incident recurrence:

1. Short-lived tokens: leverage time-limited session credentials wherever supported by platforms and infrastructure.
2. Workspace boundaries: exclude .env files, private keys, and directories containing secrets from the agent workspace; moving secrets outside the workspace does not guarantee total isolation and does not substitute for OS-level access controls.
3. Testing boundaries without network canaries: to test permissions, create a temporary isolated directory devoid of real secrets. Place a dummy file with mock placeholder content inside and verify whether the agent blocks file access, shell command execution, and reading variables via env. Do not rely on external network canary token services for basic permission validation.
4. Defense in depth: successfully intercepting reads along a single path does not prove full process isolation if the agent retains unrestricted access to the terminal or network.

Detailed architectural approaches to restricting system calls and separating permissions are discussed in the guide to managing permissions and secrets in Claude Code. Enforcing least privilege and eliminating static secrets reduces risk when delegating tasks to autonomous AI tools.