Practical response guide. Use this to prepare decisions and evidence requests. Collection and containment must follow your organisation’s authority and secure handling arrangements.
Treat the key as an access incident, not just a bill
An unexpected inference bill may be the first visible symptom of unauthorised access. It does not show how the credential escaped or everything it could reach. Record the project, credential identifier, first suspicious activity and affected owner. Do not paste the live key into email, tickets or a public support thread.
Separate three questions: whether the credential is exposed, whether it was used without authorisation and what that use enabled. A secret in a public repository can require containment even before suspicious usage is confirmed. A spending spike may also have a legitimate operational explanation that needs checking.
Disable the exposed access and coordinate continuity
Use the provider’s supported credential controls to revoke or disable the affected key under the incident owner’s authority. Identify applications depending on it and arrange controlled replacement. Avoid merely creating another key while leaving the exposed one active. Preserve available identifiers and records without delaying urgent containment.
| Action | Owner decision |
|---|---|
| Revoke or disable credential | Which production workloads will stop? |
| Replace dependent configuration | Who can update and verify each consumer? |
| Review related credentials | Was the same secret store or workstation exposed? |
| Contact provider support | Which abuse and billing records are available? |
Collect usage and control-plane evidence
Request available project activity, authentication, usage, billing and administrative records for the incident window. Record the query scope and export time. A usage total can support a cost assessment but may not identify request content or the person responsible. Do not assume detailed payload logging was enabled historically.
For Amazon Bedrock, AWS documents distinct observability options including metrics, CloudTrail and model invocation logging. Check the actual endpoint and logging configuration in use. Other providers have different retention and visibility; ask for the relevant records rather than translating one provider’s fields into another’s by assumption.
Find the exposure path before issuing permanent replacements
Review repositories, build outputs, deployment configuration, logs and developer endpoints that handled the secret. Distinguish a key committed to source from a broader compromise of the environment holding it. Removing a visible string from the latest commit does not invalidate a copied credential or remove historical copies.
Preserve the relevant history before cleanup. Check whether automation copied the same value to previews, support attachments or client-side bundles. Record confirmed locations and plausible but unverified paths separately. Expand scope when evidence indicates shared credentials or a compromised identity, rather than simply because more systems exist.
Assess more than token consumption
Determine the permissions associated with the credential at the relevant time. Could it only invoke models, or could it also interact with stored files, assistants, projects or other resources? Review actual capabilities and activity. Do not infer that an inference credential necessarily exposed all organisation data.
- Quantify confirmed unauthorised usage where records permit.
- Identify accessed resources and completed administrative changes.
- Separate provider billing questions from technical impact.
- State retention gaps and unresolved attribution.
Validate replacement and reduce recurrence
Confirm that the old credential fails through the relevant supported path and that authorised consumers use the replacement. Check for stale configuration and retries. Assign ownership for secret storage, scoped credentials and usage review. Establish an escalation threshold that someone will actually monitor.
The closure record should explain the exposure path, containment times, observed use, business impact and validation. If the event includes a compromised agent or tool server, expand into the agent response workstream. Use the scope and cost guide to understand the factors affecting an investigation.
Get help with the investigation
Atlant Security provides support for this response workstream as part of our AI incident response services. Start with the affected system, observed behaviour, business impact and urgency. We confirm availability, scope and a secure evidence channel before work begins.
Sources and review
AWS: monitoring the Bedrock runtime endpoint; NIST SP 800-61 Rev. 3.
Reviewed 24 October 2026. The decision tables are Atlant Security planning guidance. Images are conceptual illustrations, not screenshots or evidence from a customer incident.
