When a supplier warns that your provider keys may have been exposed, assume someone else can use them until the issuer revokes them. Deleting the supplier's saved copy does not revoke anything. Follow the issuer's current incident instructions.
An agent can carry most of this response. It traces every application and job that uses the key, checks what the key can reach, and watches usage at the provider. It also prepares the replacement, switches consumers over, and confirms each one recovered. Your response owner makes the containment decision. The agent makes sure that decision is fast, informed, and fully carried out.
All notices, identifiers, times, and results in this guide are fictional. Records contain key references only, never secret values.
Let the agent establish the affected credential
As soon as the notice arrives, the agent opens a response record. It logs the notice, provider account, key identifier, claimed exposure period, and response owner, and keeps confirmed facts, supplier claims, and open questions apart as the investigation changes.
A provider key, a gateway-only credential, and an application login have different issuers and revocation paths. The agent opens one record per credential so each revocation and recovery closes on its own evidence.
Let the agent trace access and dependent systems
The agent searches approved configuration and deployment records for every application, job, build step, and integration that uses the key. That includes indirect consumers that read it from a shared store. In this example it finds two: app-prod and the scheduled job nightly-report. Nobody works with a nightly job directly, so it is easy to miss, and that is exactly the consumer that fails silently after a hurried rotation.
The agent then confirms the key's granted scope and reachable resources with the issuer. Some keys only allow model requests; others reach stored files or account resources. It searches provider and application records for credentials or sessions created through the exposed access, and opens a containment item for each one it finds. Anything it cannot confirm stays marked unverified, with an owner.
The agent works from configuration references and metadata. Secret values stay out of its inputs and outputs. Software supply chain security with AI covers keeping this inventory current before an incident forces the question.
Decide containment, then let the agent carry it out
Routine rotation and suspected compromise follow different tracks. The steps below are an operating model; issuer instructions and the incident itself set the exact sequence.
Routine rotation is scheduled replacement with no suspected exposure. The agent can run it end to end under a pre-approved policy. It creates a restricted replacement, updates and verifies each consumer, then revokes the old key at the issuer.
Suspected compromise needs prompt containment, even without visible misuse. Delayed or empty usage records do not clear a potentially leaked key. The response owner chooses between two options:
- Revoke or disable the key immediately and accept that some consumers will break.
- Make a controlled replacement with a brief overlap, where issuer guidance allows it.
The agent's job is to make that choice quick and well informed. It does not wait for a complete consumer inventory before asking.
Before any replacement goes out, the agent establishes where the compromise happened. It checks the secret store, build, and deployment logs and records what it reviewed. It distributes new keys only through a trusted store and deployment path, never back into the supplier's configuration until the owner accepts the supplier's containment evidence. If your own host or build environment may be compromised, follow the advisory's cleanup or rebuild instructions first. A lack of intrusion evidence alone does not prove an environment clean.
In this example, the agent finds overnight usage at about three times the usual level, with no matching activity from either consumer. By 09:20 it has prepared two things: replacement key key-prod-015 in the team's reviewed secret store, and approval request APR-1042. The request names both consumers and what immediate revocation would break, plus the expected recovery time. The owner approves immediate revocation at 09:47.
Revocation is an approval-gated action. The agent's identity can revoke the key at the issuer only after the owner approves APR-1042, and the issuer enforces that rule. Human review and agent handoffs cover acknowledgment and escalation when an approval is slow to come.
Revocation alone does not finish the response. Recovery stays open until the last consumer is confirmed on its replacement.
Let the agent watch usage at the provider
The agent reviews provider usage and billing for the exposure period and keeps checking afterward. It assigns unexplained requests for investigation and records gaps in the data, when complete records should be available, and when it will check again.
Gateway evidence covers only traffic that passes through the gateway. A stolen provider key can bypass both the gateway and its budget, so the agent reads usage at the provider itself and applies provider-side restrictions and alerts where they exist. LLM budget management explains supported request-path coverage.
Let the agent verify each consumer and the old credential
The agent keeps the issuer's confirmation of revocation as evidence. It then confirms that every consumer runs on the replacement, including scheduled jobs. A job that has not run since the change stays unverified until the agent checks its next run.
Credential response record (illustrative)
- Exposure: Notice
SUP-2026-014, Day 0 at 09:12. Provider: production account A. Keykey-prod-014, model requests only, with no administrative access in the issuer record; it can run up billable usage. The supplier says the exposure lasted from two days before Day 0 until the notice; recorded as a supplier claim. Consumers found by the agent:app-prod,nightly-report. No related credentials or sessions found by 11:00; full recheck scheduled. Owner: response owner R.- Containment: The agent flagged unexplained usage at three times the usual level and sent
APR-1042at 09:20 with the impact of each option. The owner chose immediate revocation at 09:47. The agent revoked the key at 09:49, and the issuer confirmed revocation at 09:50. The agent reviewed the secret store, build, and deployment logs and found no intrusion evidence; the review scope is recorded. The replacement went out only through that path. The supplier configuration was excluded pending its containment evidence, and the supplier's copy was later removed as housekeeping.- Recovery:
app-prodswitched tokey-prod-015at 09:56, and the agent's checks passed. The agent updated thenightly-reportconfiguration at 10:05, but the scheduler does not allow on-demand runs, so the job stays unverified until it next runs at 01:30. Usage is partly reviewed; complete records are expected on Day 1, and the recheck is scheduled. Status: recovery incomplete; the agent checks the 01:30 run and the Day 1 usage records.
The agent keeps one record in this format per credential and gives every unknown an owner. Use the blank version to set what you expect it to report:
Credential response record (blank)
- Exposure: Notice and time ___ · Provider account and key ID ___ · Granted scope and resources ___ · Exposure period and source ___ · Consumers ___ · Related credentials or sessions ___ · Owner ___
- Containment: Routine or suspected compromise ___ · Decision, reason, owner, and time ___ · Any overlap (deadline, restrictions, responder) ___ · Trusted-environment checks and distribution path ___ · Approval ___ · Revocation time and issuer evidence ___
- Recovery: Each consumer (replacement ID, applied at, verification) ___ · Usage period, gaps, and recheck ___ · Unresolved work ___ · Status ___
Keep the response record until the work is complete
The agent tracks each step as prepared, approved, executed, and verified. It closes the record only after every consumer is verified, the final usage review is done, and any downstream access has a decision. Open items get a follow-up date, and the agent keeps them moving.
Before the next notice arrives, have the agent build and maintain a list of each key's issuer, response owner, consumers, revocation path, and trusted replacement path. Then the first hour of an incident becomes a decision rather than a search.
In AgentShelf
Configure an agent to trace consumers, prepare and carry out approved steps, and maintain the record. Owners or pre-approved policies authorize revocation. AgentShelf budgets cover supported paths, not direct use of a stolen key. See governance and cost controls, or request agents to discuss credential response.