ATLAS AML.T0113: Steal Web Session Cookie in AI

A session cookie for an AI assistant, agent console or support platform opens every conversation, connected tool and data source behind it, and AI systems add new ways to steal that cookie that classic web hardening was not designed for. MITRE ATLAS tracks this as AML.T0113 Steal Web Session Cookie, under the Credential Access tactic (AML.TA0013), mirroring ATT&CK T1539. ATLAS adds the AI-specific routes: malicious JavaScript placed in AI-rendered content, unsafe rendering of model output, and poisoned content opened by users or AI operators. This page covers those routes, the ATLAS case study, and the controls and detections that matter for AI chat interfaces, agent consoles, AI service dashboards and the support tools that display AI conversations. Browser and infostealer cookie theft in general is covered in the MITRE ATT&CK T1539 Steal Web Session Cookie guide. It is for application security engineers building AI front ends and the identity and SOC teams that protect their sessions.

Key takeaways

Model output is a new script source. In ATLAS case study AML.CS0060 a chatbot was prompted to produce HTML that was stored in chat history and later stole a human support agent's session cookie when the transcript was opened.
The victim is often the operator, not the user. Support agents, reviewers and administrators open AI transcripts and logs written partly by untrusted users, and their sessions carry the most access.
AI sessions are high-value and long-lived. ATLAS notes cookies may remain valid for long periods and can give access to chat interfaces, agents, consoles and model management dashboards without the password or MFA.
Two layers stop most of it. Encode or sanitise model output in every place it is rendered, and set session cookies to HttpOnly, Secure and SameSite with a strict Content Security Policy.
Binding and short lifetimes limit the damage. Device-bound sessions, short cookie lifetimes and re-authentication for sensitive AI actions make a stolen cookie worth far less.

What AML.T0113 adds for AI systems

ATLAS created AML.T0113 in June 2026 with maturity rated as demonstrated. The technique lists the usual sources of cookies (browser storage, process memory, network traffic and applications that hold authentication material in memory) and then three that are specific to AI systems. Those are the focus here.

AI-specific route	How it works at a high level	Who is exposed	Primary control
Script in AI-rendered content	A prompt steers the model into producing markup that the interface renders as active content	Any user who views the response	Context-aware output encoding, HTML sanitisation, CSP
Stored model output rendered later	The response is saved in history and rendered in another application or for another person	Support agents, moderators, reviewers, administrators	Sanitise before storage and again at every render point
Poisoned content opened by operators	Documents, tickets or retrieved pages carrying active content reach an AI operator's browser through the AI workflow	AI operators and analysts using consoles	Isolated rendering, CSP, least-privilege operator sessions

Once stolen, the cookie is replayed to act as the victim, which ATLAS tracks separately as AML.T0091.001 Use Alternate Authentication Material: Web Session Cookie (see AML.T0091 Use Alternate Authentication Material). The ATT&CK view of replay is in the MITRE ATT&CK T1550 Use Alternate Authentication Material Guide.

The case study: AML.CS0060

Cybernews researchers reported to Lenovo on 22 July 2025 that its customer support chatbot, Lena, could be made to produce HTML through a request that started as a normal product question. The response was saved in the conversation history and rendered without sanitisation when the conversation was loaded. When the researchers asked for a human agent, the support agent's normal step of opening the transcript rendered the stored content and sent the agent's session cookie to a researcher-controlled server. According to the researchers, a reused agent cookie could have given access to the customer support platform, including active and past customer conversations. Lenovo acknowledged the report and, according to Cybernews, had protected its systems before the public write-up on 18 August 2025.

Three lessons carry over to any AI deployment:

The chatbot was the injection point, not the target: the attack used the model to write content into a trusted application's storage.
The rendering application trusted its own database: history written by the AI was treated as safe because it came from an internal system.
The highest-value cookie belonged to a person, not the requester: escalation to a human is a normal feature, and it moved the content into a privileged session.

The rendering side of this channel, including Markdown images and links used for exfiltration, is covered in the MITRE ATLAS AML.T0077 LLM Response Rendering guide.

Hardening AI front ends and operator consoles

Treat model output as untrusted input to the browser

Encode by context: OWASP LLM05 Improper Output Handling lists model-generated JavaScript or Markdown interpreted by the browser as a direct route to XSS, and asks for output encoding and a strict Content Security Policy. Render model text as text by default.
Allowlist the formatting you support: if the interface renders Markdown or HTML, pass it through a maintained sanitiser with a fixed allowlist of elements and attributes, with no script, event handler attributes or inline styles.
Sanitise before storage and at every render: chat history is reused by support tools, analytics, exports and admin views. Each of those is a render point. See the Cross-Site Scripting (XSS) Prevention Guide.
Set content types correctly: serve stored conversations and attachments with the correct content type so that data is never rendered as HTML by accident.
Isolate rich previews: render untrusted documents and previews in a sandboxed iframe on a separate origin. See the Iframe Sandboxing and srcdoc Security Guide.

Make the cookie hard to read and worth little

Control	Setting	What it stops
HttpOnly	Session cookie not readable by JavaScript	Direct cookie reads by injected script, the AML.CS0060 pattern
Secure and __Host- prefix	HTTPS only, no Domain attribute, Path=/	Network capture and sharing across subdomains
SameSite	Strict where possible, otherwise Lax; never None without Secure	Cross-site requests riding the session
Content Security Policy	No inline script; restrict script, connect and image sources to known origins	Injected script running, and data being sent to attacker origins
Idle and absolute timeouts	Enforced server-side; shorter for operator and admin consoles	Long reuse windows for stolen cookies
Device-bound sessions	Device Bound Session Credentials (DBSC) where supported: short-lived cookies refreshed with a hardware-held key	Replay of a stolen cookie from another device
Step-up authentication	Re-authenticate for exports, agent permission changes, API key creation and admin actions	A stolen session performing the most damaging actions

HttpOnly stops script from reading the cookie, but injected script running in the victim's page can still act within the session while the page is open. That is why output encoding and CSP come first and cookie flags second. Cookie attributes in depth are in the Cookie Security Guide, and binding is in the Device-Bound Session Credentials (DBSC) Guide.

Decisions by deployment type

Customer-facing chatbot with human handover: the operator console is the crown jewel. Render transcripts as plain text, apply a strict CSP to the console, and keep operator sessions short with device binding.
Internal AI assistant on corporate SSO: the assistant session usually reaches connected mail, files and tools. Use the identity provider's session controls and conditional access, and require step-up for connector changes.
AI service and model management consoles: treat these as administrative consoles. Short sessions, phishing-resistant MFA, step-up for key creation and deployment changes, and no shared browser profiles.
Small teams using a hosted AI product: the controls are mostly the provider's. Enforce SSO with MFA, restrict who holds admin roles, and keep admin work in a dedicated browser profile.

Detection and measurement

As of ATLAS release 2026.10 no mitigation is linked directly to AML.T0113; ATLAS mitigations AML.M0024 AI Telemetry Logging and Monitoring and AML.M0033 Input and Output Validation for AI Agent Components are the closest. Detection works at two points: when content tries to steal the cookie, and when a stolen cookie is replayed.

Where	Signal
Model output and stored history	Responses containing script elements, event handler attributes or external resource references, flagged by an output scanner before storage
CSP violation reports	Blocked inline script or connections to unknown origins from chat and console pages
Prompts	Requests asking the assistant to answer in raw HTML or to embed resources, from users with no business need
Session events	The same session used from a new IP, ASN, device or user agent mid-session, or concurrently from two locations
Operator and admin activity	Bulk transcript viewing, exports or API key creation shortly after an operator opened a flagged conversation

The OWASP Session Management Cheat Sheet notes that binding to IP address or user agent is not reliable alone because of NAT and proxies, so treat changes as a risk signal and combine them with the actions taken. Never log raw session IDs: log a salted hash for correlation.

Metrics

Render point coverage: share of places that display model output (chat, history, support console, exports, admin) with encoding or sanitisation verified by test.
CSP enforcement: AI front ends and consoles with an enforced CSP that blocks inline script (target 100 percent).
Cookie hygiene: AI session cookies with HttpOnly, Secure and SameSite set, checked by automated scan.
Operator session lifetime: median and maximum session age for support and admin consoles.
Replay detections: session anomaly alerts per month and the share closed with a confirmed cause.

Testing and rollout

Map render points: list every application that displays model output or stored conversations, including third-party support and analytics tools.
Deploy CSP in report-only mode: collect violations for two to four weeks, fix legitimate inline script, then enforce. Keep the report-only header in place for new pages so regressions show up.
Add output scanning: flag responses with active markup before they are stored; start in log-only mode, then block.
Fix cookie attributes and lifetimes: roll out per application, shortest lifetimes first for operator and admin consoles.
Test with an AI red team (AML.M0035): in a test environment, try to make the assistant return active content and confirm it is rendered inert in every render point, including after handover to a human. Repeat after interface or model changes.
Roll back safely: CSP and sanitiser changes can break legitimate formatting; ship them behind configuration so one application can revert without removing the control everywhere.

Responding to a stolen AI session

Revoke, not just log out: invalidate all sessions for the affected account on the server and at the identity provider.
Check what the session reached: conversations viewed, connectors used, agent settings changed, API keys created. Rotate any key created or viewed during the session.
Find the source content: locate the stored response or document that carried the script and remove or neutralise it in every copy.
Tell affected users: if an operator session was used, customers whose conversations it could read may need to be told under your notification rules.

Common failure patterns

Sanitising only the chat window: the main interface encodes output, but the support console, export view or admin log renders the same history as HTML, as in AML.CS0060.
Trusting internal storage: treating conversation history as safe because the application wrote it.
Session cookies readable by script: no HttpOnly flag on the session cookie of an AI front end.
Long-lived operator sessions: support and admin consoles left signed in for days on shared or general-purpose browsers.
MFA treated as the last word: a cookie issued after MFA is reused without MFA. The CircleCI Breach 2023 shows a stolen SSO session that had already passed two-factor authentication giving access to systems holding customer secrets.

Framework mapping

Framework	Reference	Relevance
MITRE ATLAS	AML.T0113 Steal Web Session Cookie (AML.TA0013 Credential Access)	This technique
MITRE ATLAS	AML.T0091.001 Use Alternate Authentication Material: Web Session Cookie	Replay of the stolen cookie
MITRE ATLAS mitigations	AML.M0024, AML.M0033, AML.M0035	Logging, output validation, testing
MITRE ATT&CK	T1539 Steal Web Session Cookie; T1550.004 Web Session Cookie	Mirrored enterprise techniques
OWASP Top 10 for LLM Applications 2025	LLM05 Improper Output Handling	Model output rendered as active content

See the OWASP LLM Top 10 LLM05 Improper Output Handling Guide.

Practitioner checklist

Every application that renders model output or stored conversations is listed and tested for active content.
Model output is rendered as text by default, with an allowlist sanitiser where formatting is needed.
Chat history is sanitised before storage and again at each render point, including support consoles.
AI front ends and consoles enforce a CSP with no inline script and restricted connect and image sources.
Session cookies use HttpOnly, Secure, SameSite and the __Host- prefix.
Operator and admin sessions are short, device-bound where supported and require step-up for sensitive actions.
Session anomaly detection covers AI applications, and raw session IDs are never logged.
The response runbook revokes all sessions and rotates keys created or viewed during a stolen session.

AML.T0113 Steal Web Session Cookie: Protecting AI Assistant and Console Sessions