Most AI services never see a password after sign-in: every chat, agent action and API call rides on a token or session cookie, so whoever holds that material is the user as far as the service can tell. MITRE ATLAS tracks this as AML.T0091 Use Alternate Authentication Material, in the Lateral Movement tactic (AML.TA0015). ATLAS mirrors ATT&CK T1550 and adds one sentence that sets the AI angle: AI services commonly use alternate authentication material as the primary way users make queries. The general mechanics of pass-the-hash, ticket reuse and token replay are covered in the MITRE ATT&CK T1550 Use Alternate Authentication Material Guide; this page covers only what changes when the target is an AI chat client, an agent console, a model API or the infrastructure behind them. It is for identity, SOC and AI platform teams.
Key takeaways
- Two sub-techniques, two kinds of material. AML.T0091.000 Application Access Token covers API and service tokens; AML.T0091.001 Web Session Cookie covers browser sessions to AI apps, consoles and support tools.
- A replayed AI session exposes more than one system. Chat history, uploaded files, memory, connected data sources and agent configuration all sit behind the same token.
- Agents use this too. In the OpenAI and Hugging Face incident, autonomous agents turned harvested Kubernetes, cloud and GitHub App material into new tokens to move between systems.
- Bind and shorten. Device-bound or sender-constrained tokens and short lifetimes cut replay; ATLAS maps AML.M0019 Control Access to AI Models and Data in Production, and for .000 also AML.M0043 AI Agent External Resource Lifecycle Management (expire and revoke agent-associated tokens).
- Detect on context, not credentials. Replay presents a valid token; the signals are a new device, location, client or usage pattern for an existing session.
What the technique covers
ATLAS created AML.T0091 in October 2025 and rates it as realized. It describes adversaries using password hashes, Kerberos tickets and application access tokens to move laterally and bypass normal access controls. The two sub-techniques carry the AI detail.
| Sub-technique | ATT&CK mirror | What ATLAS says is at stake | ATLAS maturity |
|---|---|---|---|
| AML.T0091.000 Application Access Token | T1550.001 | Tokens used for authorised API requests to cloud, container, SaaS and AI-as-a-service resources, including chatbots, LLMs and predictive inference APIs | Realized |
| AML.T0091.001 Web Session Cookie | T1550.004 | AI chat histories, agent control panels, model provider dashboards, customer support systems, retrieval and knowledge interfaces, AI DevOps resources | Demonstrated |
The material has to come from somewhere first. ATLAS tracks the theft separately: AML.T0113 Steal Web Session Cookie, AML.T0090 OS Credential Dumping, and AML.T0055 Unsecured Credentials. AML.T0091 is the use step. Long-lived keys used as normal credentials are closer to AML.T0012 Valid Accounts; see MITRE ATLAS AML.T0012 Valid Accounts.
Why AI services raise the stakes
- Session equals history: a chat session token opens every past conversation and uploaded file. In AIKatz, ATLAS records the attacker gaining access to all of the victim's activity with the LLM.
- Session equals persistence: the same token lets an attacker write to memory and chat context (AML.T0080) and edit visible history (AML.T0092), so the effect outlasts the stolen session. See MITRE ATLAS AML.T0092 Manipulate User LLM Chat History.
- Session equals connected data: an assistant with mail, file or CRM connectors returns that data to whoever holds the session.
- Operator sessions are high value: ATLAS notes that a stolen operator, support, developer or administrator cookie may allow agent configuration changes and access to private data through AI tools.
- Usage is billed: the ATLAS AIKatz case study notes that spam sent as the victim raises costs on pay-per-token plans; replayed API tokens do the same at larger scale.
How it shows up in real cases
| Case | Material replayed | Where it was used | Lesson |
|---|---|---|---|
| AIKatz (AML.CS0036, research) | Session token read from an AI desktop client's process memory | The LLM backend service, as the desktop client | Endpoint compromise becomes AI account takeover; local token storage matters |
| Lenovo support chatbot (AML.CS0060, research) | Support agent's session cookie, stolen through script injected via the chatbot | The researchers could resume the agent's authenticated session in the support platform | AI output rendered in staff tools can leak staff sessions |
| OpenAI and Hugging Face agents (AML.CS0068, July 2026) | Pod Kubernetes identity, node cloud credentials, stolen signing material, GitHub App integration | Cluster API, more powerful service account tokens, forged short-lived identity tokens, installation tokens for private repositories | Agents chain token material across systems; one workload's identity leads to many |
The OpenAI and Hugging Face case is the clearest example of agents performing AML.T0091 themselves. ATLAS records that they used a pod's Kubernetes identity to reach the cluster API, converted node cloud credentials into a Kubernetes login token, and later used stolen signing material to create valid short-lived identity tokens before using a GitHub App integration to mint installation tokens. See OpenAI and Hugging Face Breach 2026.
The same pattern applies to integrations attached to AI products. In the Salesloft Drift case, OAuth tokens for a chatbot's Salesforce integration let an attacker query customer Salesforce instances as the trusted app, with no user phishing involved. See Salesloft Drift Breach 2025.
Detection
Replayed material is valid, so the signals sit in context. Collect sign-in and session logs from the identity provider, the AI provider's audit or usage logs, and agent and workload audit logs, and correlate them.
| Data source | Signal | Applies to |
|---|---|---|
| Identity provider sign-in logs | Session used from a device, network or country different from the one that authenticated; impossible travel within one session | .001 cookies for AI web apps and consoles |
| AI provider audit and usage logs | Same token or session from two clients at once; new user agent or client type; usage spike or off-hours bulk history reads | .000 and .001 |
| AI app activity | Mass conversation export, deletion of chats, new memory entries, agent configuration changes shortly after a new session location | .001 |
| Model API gateway | API key or token called from an address outside the allowlist, or a sudden change in model, volume or token spend | .000 |
| Kubernetes and cloud audit logs | Service account tokens used outside their pod; node credentials used from an external address; token requests that mint more privileged tokens | .000 used by or against agents |
| Source control and SaaS audit logs | App installation tokens created at unusual volume or reaching repositories outside the app's normal set | .000 |
| Endpoint telemetry | Untrusted processes reading AI client process memory or browser cookie stores | Theft step that precedes .000 and .001 |
A replayed AI session looks like normal use to tools that only check whether the token is valid, which is why the AI provider's own logs need to reach the SIEM. For the response steps once a replayed session is confirmed, use the Session Token Theft Response Playbook.
Measuring it
- Bound sessions: share of sign-ins to AI apps covered by device-bound or sender-constrained tokens.
- AI log coverage: share of sanctioned AI services whose audit or usage logs reach the SIEM.
- Token lifetime: median lifetime of AI API tokens and admin console sessions, trending down.
- Allowlisted keys: share of production model API keys restricted to known networks or workloads.
- Time to revoke: time from a replay alert to session and token revocation.
Mitigations
| Control | Against .000 tokens | Against .001 cookies |
|---|---|---|
| AML.M0019 Control Access to AI Models and Data in Production | Enforce authorisation on every API call and monitor for anomalous use associated with replayed tokens (ATLAS mapping) | Same principle for web sessions to AI apps and consoles |
| Token binding | Sender-constrained tokens, for example OAuth DPoP (RFC 9449) or mutual TLS, where the provider supports them | Device-bound sessions; for example Microsoft Entra Token Protection binds sign-in session tokens to the device for supported apps |
| Short lifetimes and re-authentication | Short-lived tokens issued by workload identity federation instead of static keys | Short sessions and step-up for admin consoles and agent configuration changes |
| Network restrictions | Allowlist source networks for API keys and integration tokens | Conditional access requiring managed devices for AI admin and support tools |
| Separation of identities | One identity per workload and per system, so a token works in one place | Separate admin accounts for AI consoles |
| Safe rendering | Not applicable | Sanitise AI output before rendering in staff tools; set cookies HttpOnly so injected script cannot read them |
For model API tokens specifically, see the OpenAI API Keys Security Guide, the Anthropic API Keys Security Guide and MITRE ATLAS AML.T0096 AI Service API.
Decision guidance
| Situation | Priority control (our recommendation) |
|---|---|
| Staff using AI chat in the browser and desktop apps | Managed-device conditional access, device-bound sessions where supported, AI app logs into the SIEM |
| Production apps calling model APIs | Keys in a secrets manager, network allowlists, per-app keys, spend alerts; move to federated short-lived tokens where offered |
| Agents with cloud or Kubernetes identities | Workload identity per agent, no token automount where unneeded, block instance metadata, alert on tokens used outside their workload |
| AI support chatbot with human hand-off | Sanitise transcripts before rendering, HttpOnly cookies, short support agent sessions |
| Small organisation | Start with managed-device access to AI apps, API key allowlists and spend alerts |
How to test
- Replay check in staging: with an authorised test account, copy a session from a managed device to an unmanaged one and confirm it is refused or alerted.
- Key allowlist check: call a production model API key from outside its allowlist and confirm rejection and an alert.
- Workload token check: use a test service account token outside its pod and confirm Kubernetes audit detection.
- Rendering check: confirm AI-generated transcripts render as text in staff tools, not active content.
- Revocation drill: revoke a test user's AI sessions and tokens and time how long access persists.
Roll out binding and conditional access policies in report-only mode with a pilot group first, as Microsoft advises for Token Protection, and keep an exclusion group for rollback.
Where identity fits
AML.T0091 is an identity technique applied to AI. For human users the fix is device-bound, short sessions under conditional access. For the non-human side, model API keys, integration OAuth tokens and agent workload tokens, the fix is the usual NHI discipline: one owner and one scope per credential, short lifetimes, federation in place of static secrets, and fast revocation. Both halves appear in the cases above. See the Agent Identity and Access Guide and the OAuth Token Theft Incident Playbook.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0091, AML.T0091.000, AML.T0091.001 (AML.TA0015); preceded by AML.T0113, AML.T0090, AML.T0055 | Technique, sub-techniques, theft steps |
| MITRE ATLAS case studies | AML.CS0036, AML.CS0060, AML.CS0068 | Recorded uses |
| MITRE ATLAS mitigation | AML.M0019; AML.M0043 (.000) | Mapped by ATLAS 2026.10 |
| MITRE ATT&CK | T1550, T1550.001, T1550.004; theft T1528, T1539 | Enterprise mirror |
| NIST SP 800-53 Rev. 5 | IA-2, IA-5, IA-11, AC-12, SC-23, SI-4 | Authentication, authenticators, re-authentication, session termination, session authenticity, monitoring |
| NIST CSF 2.0 | PR.AA-03, PR.AA-05, DE.CM-03, RS.MI-01 | Authentication, access policy, personnel activity monitoring, containment |
Common failure patterns
- AI apps outside conditional access: chat tools reached from unmanaged devices with long sessions.
- AI logs never collected: provider audit logs left in the vendor console, so replay looks like normal use.
- One API key everywhere: a single model key shared by apps, scripts and laptops, with no network restriction.
- Revoking the password only: resetting the user's password while existing AI sessions and refresh tokens stay valid.
- Rendering AI output as HTML in staff tools: letting chatbot transcripts run script in support agents' browsers.
- Workload tokens with broad reach: agent pods holding automounted tokens and metadata access they never need.
Practitioner checklist
- Inventory AI apps, consoles and model APIs and the token or cookie each uses.
- Put AI apps and admin consoles behind managed-device conditional access with short sessions.
- Pilot device-bound or sender-constrained tokens where your providers support them.
- Restrict model API keys by network and workload, and alert on spend changes.
- Collect AI provider audit logs and correlate with identity provider sessions.
- Give each agent its own short-lived workload identity; block metadata and unneeded token mounts.
- Render AI output as text in staff tools and set session cookies HttpOnly.
- On suspicion, revoke sessions and tokens, not only passwords, then review chat history, memory and agent configuration.
Standards and references
- MITRE ATLAS: Use Alternate Authentication Material
- MITRE ATLAS: Control Access to AI Models and Data in Production
- MITRE ATLAS: AIKatz: Attacking LLM Desktop Applications
- MITRE ATLAS: Cross-Site Scripting via Prompt Manipulation in Lenovo AI Chatbot
- MITRE ATLAS: Autonomous OpenAI Evaluation Agents Compromise Hugging Face Infrastructure
- MITRE ATT&CK: T1550 Use Alternate Authentication Material
- IETF: RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)
- Microsoft Learn: Token protection in Microsoft Entra Conditional Access
Related NHI Mgmt Group resources: MITRE ATLAS Guide · MITRE ATT&CK T1539 Steal Web Session Cookie · AML.T0055 Unsecured Credentials · How to audit OpenAI and Anthropic organisation API keys