AML.T0055 Unsecured Credentials: Finding AI Keys and Tokens Before Attackers Do

AI systems collect credentials in places traditional secret scanning was never pointed at: prompts, notebook outputs, agent and MCP configuration, training clusters and the runtime environment an agent can read for itself. MITRE ATLAS tracks the theft of insecurely stored credentials as AML.T0055 Unsecured Credentials, in the Credential Access tactic (AML.TA0013), and links it to the ATT&CK technique T1552 Unsecured Credentials. The general technique, its sub-techniques and host-level detection are covered in the MITRE ATT&CK T1552 Unsecured Credentials Guide, so this page covers only the AI-specific angle: where AI workloads leave credentials, what the ATLAS case studies show, and how to find and remove them. It is for AI platform, ML engineering and security teams responsible for model provider keys, agent credentials and the infrastructure behind them.

Source note: technique, case study and mitigation details follow the MITRE ATLAS data release 2026.10 (modified 28 October 2026). Confirm against the official text before relying on it.

Key takeaways

• ATLAS rates this technique as realised. Its case studies include incidents and exercises where credentials were taken from exposed AI compute clusters, cloud environments, public datasets and agent hosts.
• The agent is a new way to read the old locations. In several ATLAS cases the attacker never touched the host: an injected prompt made the agent read environment variables, SSH keys or its own process environment.
• AI keys are valuable on their own. ATLAS case AML.CS0030 LLMjacking: Stolen Cloud Credentials Used to Access Cloud LLM Services describes stolen cloud credentials used to access hosted models and resell that access.
• Notebooks, prompts and datasets are credential stores in practice. Treat notebook outputs, prompt templates, chat logs and uploaded datasets as places to scan, not only source code.
• Remove, then rotate, then prevent. A key found in an AI artefact has usually been copied into logs, caches or model provider history, so revoke it rather than only deleting the copy you found.

What ATLAS says AML.T0055 is

ATLAS describes adversaries searching compromised systems to find and obtain insecurely stored credentials, in plaintext files such as shell history, environment variables, operating system or application repositories, and other files such as private keys. The definition mirrors ATT&CK T1552. The technique is listed for the "Enterprise" platform, rated "Realized", created in October 2023 and last modified in May 2026. ATLAS has no technique-specific mitigation mapped to AML.T0055; the protective controls come from secrets management practice and from the agent mitigations covered below.

Three related ATLAS techniques are narrower and each has its own NHI Mgmt Group guide: MITRE ATLAS AML.T0083 Credentials from AI Agent Configuration (keys in agent and MCP configuration files), MITRE ATLAS AML.T0082 RAG Credential Harvesting (secrets retrieved from indexed content), and MITRE ATLAS AML.T0098 AI Agent Tool Credential Harvesting (secrets pulled through an agent's tools). AML.T0055 is the umbrella for everything else in AI environments.

What the ATLAS case studies show

Two patterns stand out. First, AI compute and data processing infrastructure accumulates many unrelated secrets in one place: the ShadowRay case lists SSH keys, model provider, model hub, payment, cloud and Kubernetes credentials together, and the Hugging Face case lists database, cloud, source control and signing credentials. Hugging Face's own incident post of 16 July 2026 says it revoked and rotated affected credentials, began a broader precautionary rotation and added stricter cluster admission controls. Second, an agent that can read files or run code becomes the search tool: the attacker only has to ask. The Sentry MCP agentjacking research showed coding agents running a test package that checked for credential files and environment variables with the developer's own privileges.

Where credentials sit in AI environments

Finding and removing AI credentials: a phased approach

1. Inventory AI credential types. List every model provider, model hub, vector database, agent platform and MCP server your organisation uses, and the token format each issues. Confirm your secret scanners detect each format; add custom patterns where they do not.
2. Extend scanning to AI artefacts. Point existing scanners at notebook repositories including outputs, prompt stores, agent configuration in developer home directories (through endpoint tooling), datasets before upload and RAG source spaces. Start in report-only mode.
3. Triage by reach. Rank findings by what the credential can do: an admin or organisation-level key first, then keys with spend or data access, then scoped test keys. See Developer Secret Scanning Triage.
4. Revoke and reissue, then clean. Rotate first, because the value may already sit in provider logs, caches, notebook checkpoints or chat history; then remove the copy and purge history where you can.
5. Replace with references. Move agents and notebooks to a secrets manager, workload identity or a credential helper so configuration holds a reference, not a value.
6. Block new leaks. Turn on push protection for repositories holding notebooks and agent configuration; see How to enable GitHub secret scanning push protection. Add gateway rules that flag key-shaped strings in prompts.
7. Test. Plant canary credentials in the locations above and confirm scanning, alerting and the agent controls below catch an attempt to read or use them.

Roll back by keeping the old credential's revocation reversible for a short window where the provider supports it, and by running new secret-manager references alongside old values only until the workload is confirmed working.

Limiting what an agent can read

Because injected agents are now a common route to unsecured credentials, agent controls matter as much as scanning. These ATLAS mitigations are mapped to AML.T0053 AI Agent Tool Invocation rather than to AML.T0055, but they are what stopped or would have stopped several of the cases above.

• AML.M0032 Segmentation of AI Agent Components: run agents in clean environments per run with restricted file system and network access, and isolate each agent's credentials. An agent that cannot read ~/.ssh or the CI environment cannot leak it.
• AML.M0028 Enforce Access Controls for AI Agent Tools: tools receive the identity and restrictions of the calling agent, so a file read tool cannot reach more than the agent should.
• AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data: no automatic file reads or code execution once untrusted content is in context.
• AML.M0024 AI Telemetry Logging and Monitoring: log file paths read and commands run by agents, so reads of credential locations can be alerted on.
• Keep secrets out of the agent's environment: inject short-lived credentials at the tool boundary rather than placing long-lived keys in variables the model's code can print. ATLAS case AML.CS0067 Claude Code GitHub Action Secret Exposure, which ATLAS maps to AML.T0098, shows why every tool, not only the shell, must be inside the boundary.

Tool hardening in general is covered in the AI Agent Sandboxing and Code Execution Guide.

Detection and measurement

Unexpected model usage on your account is often the first sign that an AI key has leaked; response steps are in the LLMjacking Response Playbook.

Metrics

• Scan coverage: share of notebook repositories, prompt stores, datasets and RAG sources covered by secret scanning.
• Format coverage: share of AI provider token formats in use that scanners detect.
• Time to revoke: median time from detection of an exposed AI credential to revocation.
• Static key share: share of agents and notebooks still using long-lived keys rather than references or workload identity.
• Repeat rate: findings per month in locations already cleaned, which shows whether prevention is working.

Common failure patterns

• Scanning code cells but not notebook outputs. A key printed by a debugging cell lives on in the saved output after the code is fixed.
• Deleting the leaked key from the file without rotating it. Prompt and chat copies persist in logs and provider history.
• One organisation-wide model provider key shared by every agent and notebook. A single leak exposes all spend and data, and rotation breaks everything at once.
• Exposed AI compute dashboards and job APIs. The ShadowRay case shows an unauthenticated job API giving access to every secret on the cluster.
• Long-lived secrets in agent and CI environments. Any tool that can read the environment can leak them, as AML.CS0016 shows (and AML.CS0067, mapped to AML.T0098).

Framework mapping

Practitioner checklist

• List every AI provider, model hub, vector database and MCP credential type in use, and confirm scanners detect each format.
• Scan notebooks including outputs, prompt stores, agent configuration, datasets and RAG sources.
• Rotate before cleaning, and purge copies from logs and history where possible.
• Replace static keys with secret-manager references, workload identity or credential helpers.
• Remove long-lived secrets from agent and CI environments; sandbox agents with restricted file access.
• Close exposed AI compute dashboards and job APIs; require authentication.
• Alert on agent reads of credential paths and on unusual model provider key usage.
• Plant canary credentials in AI locations and test detection.

Standards and references

• MITRE ATLAS: AML.T0055 Unsecured Credentials
• MITRE ATLAS: AML.CS0023 ShadowRay, Hijacking Exposed Ray Clusters
• MITRE ATLAS: AML.CS0068 Autonomous OpenAI Evaluation Agents Compromise Hugging Face Infrastructure
• MITRE ATT&CK: T1552 Unsecured Credentials
• OWASP: LLM02:2025 Sensitive Information Disclosure
• Hugging Face: Security incident, July 2026
• Model Context Protocol: Security Best Practices

Related NHI Mgmt Group resources: MITRE ATT&CK T1552 Unsecured Credentials Guide · LLMjacking Guide · Secrets in Prompts · MITRE ATLAS Guide