Quick answer: When an AI agent credential is compromised, revoke the agent's token — not the underlying service key — the moment you suspect a problem. Then use the access log to reconstruct what the agent touched and when. Only after containment and assessment do you decide whether the incident triggers a notification obligation. Restore access on a narrower scope than the agent had before, with the gaps the audit log exposed closed. The steps are the same whether a scanner flagged the credential, a vendor notified you, or you found it yourself in the logs.
How agent credential compromises typically surface
Agent credential incidents rarely start with a dramatic breach alert. They surface in a handful of predictable ways:
Anomalous API call patterns. A billing agent that normally makes a dozen Stripe calls a day suddenly makes several hundred, or starts hitting endpoints — refunds, payout details, customer PII — outside its normal task. Rate-limit alerts or unusual-activity flags from the service provider are often the first signal.
Security scanner alerts. Git secret scanning (GitHub push protection, Gitleaks, TruffleHog) catches a credential committed to a repository, sometimes one an agent wrote into a .env file or a config it generated. See secret scanning for AI codebases for what these scanners catch and miss.
Vendor notification. A service provider — Stripe, GitHub, OpenAI, AWS — detects unusual use of a key associated with your account and emails you directly, sometimes with the key already suspended on their end.
Manual discovery in logs. Someone reviewing access logs, a support ticket, or an unexpected charge notices a pattern that doesn't match any human or expected automated activity, and traces it back to an agent's credential.
None of these tell you the full scope on their own — they tell you where to start looking. The response from there follows the same four steps regardless of how you found out.
Step 1: Contain — revoke the agent's token, not the key
The first move is to cut the agent's access, and the mechanism matters more than it looks like it should.
If the agent connects through a credential broker — a system where the agent holds a scoped access-profile token and the broker holds the real service key — containment is immediate and surgical. You revoke the agent's profile. The next credential request from that agent returns denied. The underlying Stripe key, GitHub token, or database credential is untouched, and every other agent or system using that same underlying key keeps running.
If the agent holds the raw service key directly — the common case when a key was pasted straight into an agent's environment or prompt — you don't have that option. Revoking access means rotating the key at the provider, which invalidates it everywhere it's used: other agents, CI pipelines, deployed services, teammates' local environments. You're now doing incident response and a coordinated rotation at the same time, under time pressure, often without a complete list of everywhere the key lives.
This is the practical argument for brokered access over raw keys, and it's worth internalizing during containment even if you don't have it set up yet: the speed and precision of your very next incident depends on which model you're running today. See API key rotation vs. revocation for the fuller comparison.
Whichever mechanism you have, act on it before you've finished assessing scope. A live compromised credential accrues damage for every minute it stays active — contain first, understand fully second.
Step 2: Assess — reconstruct the blast radius from the audit log
Once the credential can no longer be used, the question becomes: what did it actually do?
A per-agent audit log lets you answer this precisely: which agent, which operations, against which resources, over what time window. If your logging is at the level of "this API key was used" rather than "this agent performed this operation," you're left inferring intent from raw call volume — which is guesswork, not assessment.
What to reconstruct:
- Which agent, and since when. Pin down the earliest anomalous call. This sets your incident window.
- Which operations. Reads are a different incident than writes. A refund issued is different from a refund attempted and denied by scope.
- Which data or resources. Customer records, payment methods, source code, infrastructure config — the categories of data touched determine downstream obligations.
- What was likely exfiltrated versus merely accessed. Access doesn't always mean the data left your systems, but you generally have to assume it did unless you can show otherwise from the log.
This step is also where scoped access pays off retroactively, not just preventively. An agent scoped to "read GitHub pull requests" that gets compromised has a blast radius bounded by what that scope permits, regardless of what the attacker wanted to do. An agent holding a full-access token has a blast radius bounded only by what the underlying service allows — which for most API keys is everything.
Step 3: Notify — figuring out if this is a reportable breach
Whether an agent credential compromise triggers a legal notification obligation depends on what step 2 turned up, not on the fact that an AI agent was involved. The frameworks don't have an AI-specific carve-out — they ask what data was accessible and what happened to it.
GDPR requires notifying the relevant supervisory authority within 72 hours of becoming aware of a breach involving personal data of EU residents, unless the breach is unlikely to result in a risk to individuals. If the agent's access included customer PII and the audit log shows access during the incident window, the clock is running from when you discovered it — not from when the compromise started. See GDPR for AI agents for how the broader obligations apply to agent access generally.
HIPAA uses a 60-day notification window (to affected individuals, HHS, and in some cases media) for breaches of unsecured protected health information, with a lower bar — most unauthorized access to PHI is presumed to be a breach unless a documented risk assessment shows low probability of compromise. An agent with any PHI-scoped access that's compromised puts you into this assessment by default. See HIPAA for AI agents.
State breach notification laws in the US generally apply to compromise of specific categories of personal information (SSNs, financial account numbers, health data, credentials) and vary by state on timing and threshold, but the general shape — assess what was exposed, notify affected individuals and sometimes regulators — is consistent.
The factors that actually decide whether you're in notification territory: what data category the agent's scope covered, whether the audit log shows that data was actually accessed (not just theoretically reachable), and whether you can demonstrate the access was contained quickly. This is exactly why step 2's precision matters — a vague "we don't know exactly what it touched" answer tends to push you toward the conservative, mandatory-notification interpretation, because you can't affirmatively rule out exposure.
None of this is legal advice — read your specific obligations under GDPR, HIPAA, or applicable state law with counsel. But the technical inputs to that legal decision are entirely in your hands during containment and assessment, which is why doing those two steps well matters even before you know whether notification applies.
Step 4: Harden — narrow the scope before you restore access
Once the incident is contained and assessed, restoring the agent to its previous access level just resets the clock on the same failure mode. The point of this step is to make the next incident smaller.
Narrow the access profile. Look at what the agent's task actually required versus what its old scope granted. Almost every incident review turns up permissions the agent never used for legitimate work — remove them. If the compromised agent only needed to create Stripe payment intents but held broader billing access, the new profile should reflect the narrower reality.
Add approval gates for the risky operations. If the audit log shows the compromised credential attempted (or succeeded at) an operation you'd want a human to sign off on — a refund over a threshold, a production deploy, a bulk data export — that's a concrete case for adding an approval step specifically on that operation going forward, not blanket friction everywhere.
Check other agents for the same over-scoping. If one agent had broader access than its task needed, others probably do too — scope creep tends to be systemic, not isolated to whichever agent happened to get compromised first. A quick audit of active access profiles against what each agent has actually called in the last 30 days catches most of this. See AI agent permissions and least privilege for AI agents for how to scope this correctly the second time.
Document what changed and why. For compliance frameworks with incident response requirements — including the notification obligations above — a written record of what was compromised, what was assessed, what was hardened, and when access was restored is itself part of the deliverable, not just internal hygiene.
Blast radius sets incident severity before the incident happens
The steps above work the same way regardless of what got compromised, but how much they matter is decided long before step 1 — by the scope you gave the agent in the first place.
A token scoped to "read GitHub pull request titles" that gets compromised is a minor incident: contain, confirm no PII was touched, done in an afternoon. A token scoped to "full Stripe admin" that gets compromised is a major incident: contain, assess against every operation Stripe's API permits, likely trigger notification review, and spend days on it.
Same containment procedure. Wildly different severity, entirely because of the scope decision made when the agent was set up — not anything about how the compromise happened. This is the practical case for narrow, per-agent scoping as a forcing function: it doesn't just reduce the chance of a bad incident, it caps how bad any single incident can be, and it makes the response calmer and faster because there's less to assess and less that could plausibly require notification.
Gazebo gives every AI agent a named, scoped identity with a per-agent audit log and instant revocation — so containment is a single action, assessment starts from a precise record instead of a guess, and the next incident is smaller because the scope was narrow from the start. See the security model or get started free.