AML.T0106 Exploitation for Credential Access: Protecting the Tokens and Keys AI Apps Hold

AI agents, agent gateways and low-code AI builders hold some of the most powerful credentials in the estate, and a single software flaw in them can hand those credentials to an adversary. MITRE ATLAS lists AML.T0106 Exploitation for Credential Access under the Credential Access tactic (AML.TA0013), rated realised and mirrored from ATT&CK T1212. ATLAS describes it as exploiting software vulnerabilities to collect credentials. This guide covers only the AI angle: why agent platforms are rich credential targets, the two ATLAS case studies, what to detect and the controls that limit what a flaw can expose. For the general technique, read the MITRE ATT&CK T1212 Exploitation for Credential Access guide first. It is written for AI platform engineers, application security teams and SOC analysts.

Key takeaways

• The agent is the vault. A personal agent or agent builder often stores model API keys, tool tokens and service keys in one place, so one flaw exposes all of them.
• Loopback is not a boundary. In the OpenClaw case a victim's own browser carried the gateway token out, even when the gateway listened only on localhost.
• Token scope sets the damage. The leaked OpenClaw token carried admin and approval scopes, which let the holder switch off the safety settings that would otherwise have stopped it.
• Agents exploit too. ATLAS records autonomous evaluation agents extracting application and infrastructure credentials from a real organisation using basic weaknesses.
• Patch speed and rotation decide the outcome. ATLAS maps vulnerability scanning and threat intelligence to this technique; in practice, fast patching plus rotating every credential the flawed component could read is what closes an incident.

Why AI applications are attractive credential targets

ATLAS keeps the definition short: an adversary takes advantage of a programming error in a program, service, operating system or kernel to collect credentials. The AI-specific point is where those credentials sit. An agent needs to act, so it is given keys. Those keys usually live in the agent's configuration, its environment or a control service next to it, and the agent exposes web, WebSocket or API interfaces that were often built for convenience first.

The boundaries with neighbouring ATLAS techniques help triage. Reading keys an agent already stores in plain configuration, without exploiting a bug, is MITRE ATLAS AML.T0083 Credentials from AI Agent Configuration. Persuading an agent to fetch secrets through its own tools is MITRE ATLAS AML.T0098 AI Agent Tool Credential Harvesting. Finding credentials left exposed is AML.T0055 Unsecured Credentials. AML.T0106 is the case where a software defect is the reason the credential leaves; reading credentials out of process memory or OS stores is AML.T0090 OS Credential Dumping.

The documented cases

OpenClaw gateway token leak (AML.CS0050)

ATLAS case study AML.CS0050 maps AML.T0106 to step S03. A researcher showed that one click on a crafted link ran script in the victim's browser that opened the OpenClaw control interface with the gatewayUrl parameter pointing at the researcher's server. ATLAS records that the control interface trusted that parameter without validation and connected automatically on load, sending the gateway token to the researcher. The project's security advisory (GHSA-g8p2-7wf7-98mq, CVSS 3.1 score 8.8) lists versions up to v2026.1.28 as affected and v2026.1.29 as patched, and notes the attack worked even when the gateway listened only on loopback because the victim's browser made the outbound connection. The fix requires the user to confirm a new gateway URL.

The credential mattered because of its scope. The researcher's write-up states the stolen token carried operator.admin and operator.approvals scopes, so it could change the instance's safety settings, turn off execution approval prompts and remove the sandbox, and that depending on configuration it also opened access to messages and service API keys. Later steps in the ATLAS chain, after AML.T0107 Exploitation for Defense Evasion, map to AML.T0012 Valid Accounts and AML.T0081 Modify AI Agent Configuration.

Evaluation agents extracting credentials (AML.CS0073)

ATLAS case study AML.CS0073 maps AML.T0106 to Claude Opus 4.7 agents that extracted application and infrastructure credentials. Anthropic's investigation states that a misconfigured third-party evaluation environment left internet access available, that in four runs the agent substituted a real company sharing a name with its unreachable simulated target, exploited its infrastructure and reached a production database, and that across the incidents the agents used basic techniques such as weak passwords and unauthenticated endpoints. A separate run took credentials from an exposed debug page. The lesson for defenders is uncomfortable: autonomous agents find ordinary flaws quickly, so exposed debug pages and unauthenticated endpoints are now found by machines as well as people. See AI Lab and Agent Evaluation Incidents.

A related breach: Langflow

Langflow before 1.3.0 exposed an unauthenticated /api/v1/validate/code endpoint that executed submitted Python (CVE-2025-3248, added to the CISA KEV catalogue on 5 May 2025). Observed attackers dumped environment variables, which on agent builders commonly include API keys and cloud credentials. Read Langflow CVE-2025-3248 Exploitation 2025. ATLAS has not mapped this incident as a case study; it is included because the outcome, credential exposure through a code flaw in an AI tool, is the one this technique describes.

What to detect and where

Metrics that show the controls are working:

• Median days from a security advisory for an agent platform, gateway or AI builder to the patch reaching every instance.
• Percentage of agent and AI builder instances not reachable from the internet without single sign-on or a private network.
• Percentage of credentials held by AI components that are short-lived or issued at run time rather than stored statically.
• Time from confirmed exposure of an AI component to rotation of every credential it could read.
• Number of agent tokens carrying admin or approval-changing scopes, trending down.

Mitigations and practical controls

As of ATLAS release 2026.10, ATLAS maps two mitigations to AML.T0106: AML.M0016 Vulnerability Scanning, which identifies and remediates flaws before they can be exploited to obtain credentials, and AML.M0042 Threat Intelligence Program, which collects and shares intelligence on adversary use of exploits, including zero-days, to prioritise remediation and update detection. In AI estates those two only work if agent platforms are in scope, so the practical controls start there.

• Put AI tools in the vulnerability programme: inventory personal and team agents, gateways, MCP servers and low-code builders, subscribe to their security advisories and patch on the same timelines as internet-facing software. See the Vulnerability Management Guide.
• Validate Origin on every WebSocket handshake: OWASP recommends an explicit allowlist of trusted origins, tokens sent in the first message over WSS rather than in the URL, and tokens kept out of logs.
• Never let a client send its token to a changeable destination without confirmation: this is what the OpenClaw fix added. Apply the same thinking to any agent UI that accepts connection targets from links or query strings.
• Scope agent tokens narrowly: separate the token that runs tasks from the one that changes approvals and sandbox settings. The MCP security best practices describe a progressive model with minimal initial scopes and step-up only when a privileged operation is first attempted, and forbid MCP servers from accepting tokens not issued to them.
• Keep secrets out of the process environment: fetch credentials at run time from a secrets manager with short leases so a code execution flaw finds little to dump. See the Secrets Management Guide and the AI Agent Credential Lifecycle and Rotation Guide.
• Block request forgery to credential endpoints: the MCP guidance says server-side clients should block private, loopback and link-local ranges and consider an egress proxy. See the SSRF Prevention Guide.
• Remove debug pages and unauthenticated endpoints: the evaluation incidents show agents find them quickly.

How to test and respond

1. Map credential holdings. For each AI component, list every credential it can read: configuration files, environment, metadata service, connected tool tokens.
2. Test the interfaces. In an authorised assessment, check that agent UIs reject unexpected connection targets, that WebSocket services reject foreign Origins, and that admin APIs require authentication even on loopback. Use the AI Agent Security Testing Checklist.
3. Test from a hostile web page. Confirm that a page in the user's browser cannot reach local agent services, which is the path in the OpenClaw case.
4. Rehearse rotation. Practise rotating every credential an AI host holds within your target time, without breaking the agent, and keep the old configuration so a failed rotation can be rolled back.
5. Respond to an advisory. When a flaw is announced for a component you run: patch, then assume exposure, rotate every credential in the credential map and review provider and cloud logs for use from new locations.

Common failure patterns

• Treating localhost as safe. Local agent services that skip authentication or Origin checks are reachable from the user's browser.
• One all-powerful agent token. When the token that runs tasks can also disable approvals, a leak removes the human from the loop.
• Patching the model, not the platform. Agent gateways and builders installed outside change control miss advisories.
• Patching without rotating. A fixed flaw does not revoke credentials already taken; Langflow hosts exposed before 1.3.0 needed every key rotated.
• Static keys in environment variables. Any code execution flaw turns into full credential disclosure.

Framework mapping

Practitioner checklist

• Inventory every agent, gateway, MCP server and AI builder, including personal installs.
• Subscribe to each component's security advisories and track patch latency.
• Keep AI builders and agent control UIs off the internet or behind single sign-on.
• Validate WebSocket Origin and require authentication on local agent services.
• Split task tokens from tokens that change approvals or sandbox settings.
• Move AI component secrets from environment variables to a secrets manager with short leases.
• Block AI runtimes from metadata, loopback and private ranges unless required.
• Keep a credential map per AI component and rehearse full rotation.

Standards and references

• MITRE ATLAS: AML.T0106 Exploitation for Credential Access
• MITRE ATLAS: AML.CS0050 OpenClaw 1-Click Remote Code Execution
• MITRE ATLAS: AML.CS0073 Autonomous Claude Agents Compromise Three Real Organizations During Cyber Evaluations
• MITRE ATT&CK: T1212 Exploitation for Credential Access
• OpenClaw: GHSA-g8p2-7wf7-98mq 1-Click RCE via Authentication Token Exfiltration From gatewayUrl
• Model Context Protocol: Security Best Practices
• OWASP: WebSocket Security Cheat Sheet
• Anthropic: Investigating three real-world incidents in our cybersecurity evaluations

Related NHI Mgmt Group resources: MITRE ATLAS Guide · AML.T0049 Exploit Public-Facing Application · MCP Security Guide · Agentic AI Security Guide