AI Agent Credential Compromise Playbook Template

When an AI agent's credential is stolen, leaked or misused, the attacker inherits everything the agent was trusted to do on behalf of every user and system that delegated to it, and revoking the one secret you found rarely ends the access. Agents typically hold a mix of credentials: a model provider API key, OAuth access and refresh tokens granted by users, tokens obtained through token exchange, MCP server credentials, cloud workload identity and secrets placed in their tool configuration. This playbook template sets out triggers, roles, decision points, the order of revocation across that delegation graph, how to trace what the agent (or the attacker using its identity) actually did, and the evidence to preserve. It is for security operations, identity and AI platform teams, with decision points for the incident manager. Replace the bracketed text before adoption.

How to use this template

Replace text in square brackets, such as [Organisation], [Agent Platform Owner] and [SIEM], with your own names. "Must" is mandatory; "should" is recommended.
Decision points are marked D1 to D5. Record each decision, who made it and when, in the incident log.
This playbook covers the credential branch of an agent incident. For prompt injection, memory poisoning or misbehaviour without credential loss, use the AI Agent Incident Response Playbook. For MCP server compromise, use the MCP Incident Response Playbook.
Preventive lifecycle controls (issuance, scoping, rotation) are in the AI Agent Credential Lifecycle and Rotation Guide and are not repeated here.
Practise this playbook at least yearly with a scenario from the Tabletop Exercise Scenario Pack.

1. Scope and triggers

1.1 This playbook applies when any credential used by an AI agent operated by, or acting for, [Organisation] is, or may be, held or used by anyone other than that agent.

Credential class	Typical location	What the holder can do
Model provider API key	Agent runtime configuration, environment variables, notebooks	Run models at [Organisation]'s cost, read stored files or assistants where the key allows it
Delegated OAuth access and refresh tokens	Agent token store, connector configuration	Act as each user who granted consent, within the granted scopes, until revoked or expired
Exchanged or downstream tokens	Issued through RFC 8693 token exchange or by tool servers	Call downstream APIs as the agent on behalf of a user
MCP server or tool credentials	MCP client configuration, tool secrets	Invoke the tools the agent can reach
Workload identity of the agent runtime	Cloud role, service account, Kubernetes service account	Everything the runtime's identity is permitted to do
Agent platform identity or claim token	Agent registry, agent social or marketplace platforms	Impersonate the agent itself, change its posts, settings or listings

1.2 Triggers: a secret scanning alert or provider notification for an agent key; a credential found in a prompt, conversation log, trace or agent memory; a platform breach notice from an agent or model provider; tool calls or API requests from the agent identity outside its normal sources, hours or volumes; unexpected model spend; a canary credential placed in the agent's context being used; a user reporting actions they did not request.

1.3 Relevant ATT&CK techniques: T1528 Steal Application Access Token, T1550.001 Application Access Token (use of stolen tokens), T1552.001 Credentials In Files, T1078.004 Cloud Accounts, T1098.001 Additional Cloud Credentials (persistence) and T1496.004 Cloud Service Hijacking (stolen model access). OWASP Non-Human Identities Top 10 2025 risks most often involved are NHI2 Secret Leakage, NHI5 Overprivileged NHI, NHI7 Long-Lived Secrets and NHI9 NHI Reuse.

2. Roles and contacts

Role	Responsibility	Named contact
[Incident Manager]	Owns the incident, decisions D1 to D5 and the timeline	[Name, phone]
[Agent Owner]	Business and technical owner of the agent; knows its tools, users and normal behaviour	[From agent inventory]
[Agent Platform Owner]	Stops or pauses the agent, changes its configuration, exports traces	[Name]
[Identity Engineer]	Revokes tokens and grants at the identity provider and authorisation servers, disables client registrations	[Name]
[Cloud Platform Owner]	Revokes workload identity sessions and reviews cloud resources	[Name]
[SOC Analyst]	Builds the action timeline from identity, tool and API logs	[Rota]
[Downstream System Owners]	Review what the agent did in each connected system	[Per system]
[Legal and Privacy]	Notification decisions	[DPO, counsel]

2.1 Revocation rights must be granted before an incident: responders need permission to pause the agent, revoke OAuth grants for the agent's client across all users, disable the client registration, and revoke cloud role sessions.

3. Detection and triage

Record the exposure: which credential, where it appeared, first possible exposure time and detection time. Preserve the location (repository, log, trace, conversation) before anything is deleted.
Identify the agent and its owner from the agent inventory: agent identity, client ID, runtime identity and the users or teams that delegated to it.
Map the delegation graph: every user who granted consent, every scope, every token exchanged from the agent's tokens, every tool or MCP server it can call and every secret in its configuration. See Revoking Delegated Access During an Active Agent Incident.
Check for use since first exposure: authorisation server token events, API calls carrying the agent's client ID, model provider usage for the key, and tool call logs.
Check whether the agent itself is compromised (prompt injection, poisoned memory, malicious tool) or only its credential. If the agent is still acting under attacker influence, its next refreshed token is also the attacker's.

D1: Severity. Critical: evidence of use by an unknown party, or a credential with write access to production data, payments or identity systems. High: public exposure of an active credential, or delegated tokens for many users. Medium: internal exposure, narrow read-only scope, no evidence of use.

4. Containment: revoke the delegations

D2: Pause the agent or keep it running? For Critical, pause the agent and accept the service impact; the [Incident Manager] decides. For High and Medium where the agent itself is not under attacker influence, rotate first and keep it running on new credentials.

Revoke in this order, so that no credential can be used to obtain another:

Root credentials that mint others: the agent's OAuth client secret or private key, its workload identity, and any secret that can request new tokens. Disable or rotate the client registration so no new tokens are issued to the old client credentials.
Refresh tokens and grants: revoke every refresh token and consent grant held by the agent's client, for all users. RFC 7009 states that revoking a refresh token invalidates access tokens from the same grant only where the server supports access token revocation.
Downstream and exchanged tokens: revoke tokens issued through token exchange and at each tool server. Where tokens are self-contained JWTs that resource servers validate locally, they remain usable until expiry: shorten lifetimes, rotate the signing key if forgery is possible, or block the agent's client ID at the resource servers. The MCP authorization specification requires MCP servers to accept only tokens issued for them and forbids passing a client's token through to upstream APIs; if a stolen token worked at more than one server, record that as a root cause.
Static secrets: rotate the model provider API key, MCP and tool credentials, and any third-party keys the agent could see in its context, memory or configuration.
Cloud sessions: revoke active sessions for the runtime's role and remove any credentials or roles created by the agent identity during the window.

4.1 Rollback: keep the old configuration exported (without secret values) so the agent can be restored with new credentials. Do not reactivate a revoked credential to restore service; issue a new one.

4.2 Where the delegation is to a third-party agent or integration, ask the provider to revoke all tokens for the integration and confirm in writing. In the Salesloft Drift breach, stolen OAuth tokens for a chatbot integration were used to export data from many organisations until all active access and refresh tokens for the application were revoked.

5. Tracing the agent's actions

5.1 The question for every downstream system is: which actions under the agent's identity were requested by a legitimate user or task, and which were not. Build one timeline across these sources.

Source	What it shows	Key fields
Authorisation server and identity provider logs	Token issuance, refresh, exchange and consent events	client ID, subject, actor, scopes, audience, source IP
Token claims	Who the agent acted for	RFC 8693 `act` claim: the outermost `act` is the current actor; nested ones are prior actors
Agent platform traces	Task, prompt, plan and tool calls in order	session or run ID, user, tool name, arguments, result
MCP server and tool logs	Calls actually executed	client identity, token audience, tool, parameters
Downstream API and SaaS audit logs	Data read, changed or exported	client ID, user, object, volume
Model provider usage	Model calls made with the key	key ID, project, model, volume, source
Cloud audit logs	Actions by the runtime identity	role session, API action, region

5.2 Match each downstream action to an agent run and a requesting user. Actions with no matching run, or from sources other than the agent runtime, are attributed to the attacker. See Agent Activity Timeline Reconstruction from Tool Calls and Identity Logs.

D3: Scope of data impact. The [Incident Manager] decides, with [Legal and Privacy], which systems and data sets are in scope for notification based on the timeline.

6. Eradication

Remove persistence: OAuth clients, consent grants, API keys, cloud credentials or webhooks created by the agent identity or the attacker in the window.
Clean the agent's context: remove secrets from prompts, memory, conversation history, traces and configuration files. Secrets must be injected at runtime from a vault, not stored where the model can read them; see Runtime Secrets Injection for AI Agents Without Prompt Exposure.
Separate shared credentials: if several agents used one credential, give each its own before restoring. See Shared credentials between AI agents.
Fix the root cause: leaked in code, exposed through a platform breach, extracted by prompt injection, or stolen from the runtime. In the Moltbook database exposure, agent API tokens and private agent conversations containing third-party keys were exposed together, so owners had to rotate both the agent key and every key the agent had seen.

7. Recovery

Issue new credentials with narrower scope than before: audience-restricted, short-lived access tokens, sender-constrained where supported (RFC 9700 recommends this, using mutual TLS or DPoP), and only the scopes the agent's tasks need.
Restore the agent in a limited mode (read-only tools or human approval for actions) for [N] days while monitoring.
Ask users to re-consent to the new client only where the agent still needs delegated access.
Confirm old credentials fail: test each revoked token and key and record the result.

D4: Return to full autonomy. The [Agent Owner] and [Incident Manager] agree when monitoring shows no anomalous use for [N] days.

8. Communication and notification

Users who delegated to the agent: tell them their grant was revoked, what the agent did on their behalf in the window, and whether they need to act.
Regulators: where personal data was accessed, apply the relevant regime; under GDPR Article 33 the controller notifies the supervisory authority within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals. See the Data Breach Notification Checklist.
Providers: report misuse of model provider keys or third-party tokens to the provider.

D5: External notification. [Legal and Privacy] decides, recording the reasoning.

9. Post-incident review

9.1 Within [10] working days, review: how the credential was exposed, how long until detection, whether the delegation graph was known before the incident, which revocations failed or were slow, and which tokens stayed valid after revocation. Record changes to agent credential design with owners and dates.

Implementation guidance

Before an incident. Keep an agent inventory with owner, client ID, runtime identity, tools and delegating users. Pre-grant revocation rights to responders. Place canary credentials in agent contexts so extraction is detected; see AI Agent Honeytokens and Canaries. Prefer token exchange with act claims over shared static keys so actions remain attributable, and give every agent its own client registration.

Small and large organisations. A small team with a few agents should start with an inventory, per-agent keys and provider spend alerts. A large organisation should automate D2 for Critical cases (pause the agent and revoke its client's grants on a high-confidence alert) and feed authorisation server, agent trace and tool logs into [SIEM] with a shared run ID.

Framework mapping.

Area	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Agent identities and credentials	PR.AA-01, PR.AA-05	IA-4, IA-5, AC-2, AC-6
Action tracing	RS.AN-03, DE.AE-02	AU-6
Containment and eradication	RS.MI-01, RS.MI-02	IR-4
Notification	RS.MA-01	IR-6

Metrics. Time from detection to revocation of all refresh tokens and grants for the agent's client; share of agents with a mapped delegation graph; share of agent actions attributable to a requesting user; number of agents sharing a credential (target zero); share of agent credentials that are short-lived.

Common failure patterns.

Rotating the model key but leaving users' refresh tokens for the agent's client active.
Revoking refresh tokens and assuming access tokens are dead when resource servers validate JWTs locally.
Restarting the agent while it is still under attacker influence, so it requests fresh tokens for the attacker.
Leaving secrets in the agent's memory or conversation history after rotation.
Not looking for keys other people leaked: agents will use leaked credentials they find, as the OpenAI agents and Census API keys case showed, so restrict agents to credentials issued for their tasks.

AI Agent Credential Compromise Playbook: Revoke Delegations and Trace Actions