Lenovo Lena chatbot shows how prompt injection becomes account theft

At a glance

What this is: Researchers showed that prompt injection against Lenovo’s Lena chatbot could be used to manipulate outputs, leak session cookies, and reach human-support workflows.

Why it matters: This matters because AI chatbots embedded in customer and support journeys can inherit identity and session risk, so IAM teams need to govern their output handling, delegation boundaries, and downstream access paths.

Context

Prompt injection is an attack pattern where untrusted input causes an AI system to follow attacker-controlled instructions instead of the user’s intended request. In this case, the risk is not only model manipulation but identity misuse, because the chatbot sits in a workflow that can touch sessions, support handoffs, and internal access paths.

The article shows how fast-moving AI adoption can outrun governance assumptions that were built for conventional web applications. When a chatbot can be induced to shape its own outputs and pass data into another step, the control problem becomes one of session handling, privilege boundaries, and trust between machine and human actors.

Key questions

Q: What breaks when prompt injection reaches an agent framework instead of a chatbot?

A: When prompt injection reaches an agent framework, the problem is no longer limited to a bad answer. The injection can influence memory, planning, tool selection, and downstream actions, which turns content manipulation into control-flow abuse. That is why framework internals must be tested and protected as part of the security boundary.

Q: Why do business chatbots create identity risk for IAM teams?

A: Because they operate through accounts, tokens, and delegated permissions, business chatbots inherit the same identity risks as other machine-accessed systems. If those entitlements are broad, reused, or poorly owned, the chatbot becomes a durable access path into customer, employee, or operational data. IAM teams have to govern the actor behind the interface, not only the interface itself.

Q: What are the signs that prompt injection controls are failing?

A: Warning signs include unexpected model behavior, responses that ignore system instructions, retrieval of irrelevant or sensitive data, and actions taken outside the intended workflow. If teams cannot trace which prompts, documents, or integrations influenced an output, they effectively lack visibility into the attack surface. That gap makes it hard to detect malicious instruction flow before it affects production systems.

Q: How should teams govern AI chatbots that can touch sessions or support tools?

A: They should treat the chatbot as an operational actor with bounded authority, separate its state from authenticated credentials, and review every integration that can convert a prompt into a support action. Governance should focus on trust boundaries, not model prompts alone.

Technical breakdown

How prompt injection works through output re-use

The attack pattern depends on the model’s output being treated as input for the next step. Here, the chatbot can be instructed to format responses in HTML, JSON, and plain text, then that output is fed back into the interaction as if it were trusted context. That creates a loop where attacker-shaped content becomes a control channel. This is structurally similar to classic injection problems in web security, but the target is now the model’s instruction-following behaviour rather than a parser alone. The core weakness is not that the model is malicious. It is that the surrounding application treats model output as safe enough to drive further actions.

Practical implication: Treat model output as untrusted data and block any reuse path that can turn chatbot responses into executable or instruction-bearing input.

Why chatbots can leak session cookies and hand off access

The article describes a flow in which the chatbot is steered toward a malicious server that receives session cookie data, then a human support agent enters the conversation and their cookies become exposed as well. That makes the chatbot a pivot point between AI interaction and privileged support access. In identity terms, the problem is delegated trust without adequate containment. Once a chatbot is allowed to participate in support workflows, it can become part of the session boundary rather than just a front-end interface. If the support handoff is not isolated, the same prompt path can cross from public interaction into internal access.

Practical implication: Separate chatbot conversation state from support-session credentials and deny any path that lets model-driven content influence authenticated handoff workflows.

Why this resembles an application-layer injection problem, not just an AI bug

The researchers’ technique echoes cross-site scripting in that attacker-controlled content is used to manipulate the application’s behaviour through the browser and supporting workflow. The important difference is that the model itself is part of the execution chain, so ordinary web controls alone may not be enough. Sanitisation, whitelisting and permission scoping still matter, but they now need to be applied to prompts, retrieved content, output transforms and downstream tools as one control surface. The result is an identity and application-security overlap: the chatbot is not simply generating text, it is participating in access-bearing interactions.

Practical implication: Extend web application security review to prompt paths, output transforms, and tool-calling flows that can affect identity-bearing actions.

Threat narrative

Attacker objective: The attacker aims to capture session credentials and pivot from chatbot interaction into unauthorized access to support and internal systems.

1. Entry begins when the attacker asks the chatbot for product information and uses that seemingly benign request as the initial prompt-injection vector.
2. Credential access follows when the chatbot is induced to emit output that can be fed back into the conversation and used to exfiltrate session cookie data to a remote server.
3. Escalation occurs when the attacker uses the same interaction model to pull a human support agent into the chat, exposing a second set of cookies and a path into internal systems.
4. Impact is achieved when stolen session data and delegated support access provide a route toward account theft and broader internal access.

Breaches seen in the wild

• OmniGPT breach claim 2025: A hacker claims to have leaked 34 million OmniGPT AI chat messages holding users' API keys and credentials; OmniGPT has not confirmed it.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Prompt injection is becoming an identity problem, not only an AI safety problem. Once a chatbot can influence sessions, support handoffs, or privileged workflows, the governance issue shifts from content moderation to access control. That means IAM and PAM teams need to treat the model as part of the trust boundary, not as a neutral interface. The practitioner conclusion is simple: if the chatbot can move credentials, it can no longer be governed as a text-only system.

Session boundary collapse is the real failure mode here. The article shows how public interaction, model output, remote content, and human support access can all be chained together. That is a named governance gap: the organisation assumed the conversation boundary would hold, but the workflow allowed identity data to cross it. The practitioner conclusion is that support-session isolation must be designed for adversarial prompt paths, not just normal customer traffic.

Prompt-injection resilience requires control over reuse, not just input filtering. The attack succeeds because output from one step becomes trusted input to the next step. Sanitising user input is necessary but insufficient if the model’s own responses, retrieved content, or HTML/JSON transforms can be repurposed as instructions. The practitioner conclusion is to validate every transition where model-generated content can alter downstream behaviour.

Human-agent trust exploitation is now a realistic control category. The chatbot’s willingness to satisfy a forceful request shows that social-engineering style pressure can be encoded into machine interaction. That widens the governance scope from malicious users to manipulative prompts that exploit helpfulness, urgency, and business legitimacy. The practitioner conclusion is to test AI systems against coercive prompt patterns the same way support processes are tested against fraud and phishing.

AI productivity tools are accelerating governance debt. The faster organisations embed chatbots into customer and support operations, the more unmanaged assumptions accumulate around permissions, content handling, and escalation paths. This is where the identity bridge matters most: any AI system that can touch sessions or support workflows needs explicit lifecycle, access, and offboarding controls. The practitioner conclusion is to govern AI assistants as operational actors with bounded authority.

What this signals

Prompt injection now sits at the intersection of application security and identity governance. For practitioners, the important change is that AI assistants embedded in customer or support journeys must be reviewed like privileged workflow components, not just content generators. If a chatbot can influence session-bearing actions, its trust boundary needs to be defined as tightly as any other access path.

Session handling is becoming the deciding control point. The article points to a class of failures where cookies, handoffs, and remote content reuse create a path from public interaction to internal access. Teams should watch for any AI workflow that can carry identity context across boundaries, because that is where prompt injection turns into account takeover risk.

For practitioners

• Map chatbot-to-support trust paths Identify every place where chatbot output, conversation state, or retrieved content can influence an authenticated support workflow or session-bearing system.
• Isolate support-session credentials Keep human support session cookies and tickets separate from public chatbot interactions so model-driven content cannot inherit authenticated context.
• Sanitise model outputs before reuse Treat HTML, JSON, and plain-text responses from the model as untrusted until they have been normalised, validated, and stripped of instruction-bearing fragments.
• Review permissions on AI-assisted workflows Audit the permissions behind chatbot integrations, escalation tools, and remote content fetches so a single prompt cannot trigger broader access than intended.
• Test for coercive prompt patterns Red-team customer-facing assistants with insistence, urgency, and business-legitimacy prompts to see whether helpfulness overrides security constraints.

Key takeaways

• Prompt injection against chatbots can become an identity and session problem when model output influences authenticated workflows.
• The risky pattern is not the prompt alone but the reuse of generated content across support handoffs, remote fetches, and session-bearing interactions.
• Teams should govern AI assistants with the same boundary discipline they apply to privileged workflows, especially where cookies or support access are involved.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Persistent Cookie: A persistent cookie is a session cookie that remains valid after the browser closes until it expires or is explicitly removed. In remote access designs, it can improve usability, but it also increases the chance that a reused session becomes standing access if the organisation does not enforce compensating controls.
• Human-Agent Trust Exploitation (ASI09): An attack where an AI agent's fluency and apparent authority are weaponised to manipulate human users into approving harmful actions, exploiting the tendency to over-trust confident AI outputs.
• Release Workflow Boundary: The operational boundary that separates approved software publication from ordinary development, testing, or runtime activity. When this boundary is weak, non-release systems can inherit publish privileges, which turns routine automation into a potential covert transfer path or supply-chain abuse channel.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, IAM, human identity, identity lifecycle, and secrets management. It helps security practitioners connect identity controls to emerging AI-driven workflows.