Traditional cyber security tools fall short for LLM risk

At a glance

What this is: The article argues that conventional cyber security tools cannot adequately govern LLM risk because LLMs behave more like contextual, interactive systems than static applications.

Why it matters: This matters because IAM, NHI, and security teams need controls that account for conversational access, hidden usage paths, and model-mediated data movement, not just perimeter or data-store inspection.

👉 Read Lasso Security's analysis of common cyber security tools and LLM risk

Context

Large language models create a governance gap because they do not behave like ordinary web apps or fixed data stores. They accept natural language, can trigger actions inside integrated tools, and may be accessed through many untracked paths, which makes traditional inspection and policy enforcement incomplete.

For identity teams, the key issue is not just data leakage. It is that LLMs increasingly sit inside workflows where access, context, and execution converge, so existing browser, DLP, and DSPM models miss both Shadow AI use and the identity conditions behind each interaction.

Key questions

Q: How should security teams govern LLM use when browser security is not enough?

A: Treat browser controls as one layer only. Teams should add discovery of all LLM entry points, logging of prompts and responses, and monitoring of connected tools or backend actions. Governance must cover the full interaction path because the risky behaviour often happens after the page boundary, not inside the browser itself.

Q: Why do DLP and DSPM miss many LLM risks?

A: DLP and DSPM were built for static data inspection, not for conversational systems that reveal or transform data over multiple turns. They miss prompt injection, incremental exfiltration, and model-side execution because the risk is in context and behaviour, not only in a single outbound record or stored dataset.

Q: What do organisations get wrong about Shadow AI discovery?

A: They often look for a single sanctioned platform instead of mapping every way employees can reach LLMs. Shadow AI includes direct web use, third-party applications, embedded models, and API calls, so discovery must focus on usage paths, not just approved vendors.

Q: How can teams decide whether an LLM needs stricter governance?

A: Start with the data it can access, the tools it can call, and whether its responses can influence internal workflows. The more an LLM can read, generate, or trigger inside business systems, the more it belongs under identity, logging, and access governance rather than only content filtering.

Technical breakdown

Why browser security misses LLM interactions

Browser security is designed to police the browser boundary, web rendering, and known web-borne threats. LLM interactions are different because the relevant behaviour happens in a live, conversational session and may extend into plugins, APIs, or backend execution paths that the browser cannot inspect. Once the model or connected tool executes an action outside the page context, browser-level controls lose visibility into intent, scope, and downstream effects. Prompt injection also breaks the assumption that page content is passive. The model can be induced to treat attacker-controlled text as instruction, which is not the same threat class as a malicious website.

Practical implication: teams should treat browser security as only one control layer and add visibility into model prompts, tool calls, and backend execution.

Why DLP fails against prompt injection and incremental exfiltration

DLP works best when it can match known patterns, inspect content at the boundary, and flag obvious sensitive-data movement. LLM abuse changes the problem because attackers can elicit data gradually through conversation, rather than triggering a single obvious leak. That makes incremental exfiltration, jailbreaks, and manipulated context harder to spot. DLP also tends to focus on data leaving the organisation, while LLM use can introduce risky content into internal workflows as well. In other words, the control was built for static inspection of transactions, not for adversarial dialogue that changes shape over time.

Practical implication: security teams need LLM-aware monitoring for prompt and response content, not just pattern matching on outbound data.

Why DSPM treats LLMs like the wrong kind of data store

DSPM classifies and protects data in storage systems such as warehouses and databases, where the main question is what data exists and who can reach it. LLMs are not passive stores. They are dynamic interfaces that can reveal, transform, or recombine data based on context, user prompts, and connected tools. That means the relevant risk is not just stored sensitivity, but semantic leakage through the model interaction itself. DSPM also struggles with on-prem and web-based LLM use because the exposure point is often the conversation, not the repository.

Practical implication: organisations should pair DSPM with controls that understand runtime model behaviour and conversational access patterns.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

LLM security exposes a control mismatch, not just a tooling gap. Browser security, DLP, and DSPM each solve a narrower problem than LLM governance requires. The article shows that the risk sits in the interaction layer, where users, prompts, data, and tool execution meet. Practitioners should stop treating LLMs as if they were ordinary web sessions or static data repositories.

Shadow AI is an identity discovery problem before it is a content problem. If organisations cannot identify which LLMs are in use, they cannot govern access, logging, or acceptable data paths. That makes model discovery and usage mapping a prerequisite for any meaningful NHI or AI governance programme. Teams should treat untracked model access as unmanaged identity exposure.

Context is the named control gap that older security tools cannot see. Traditional tools were designed for deterministic transactions, but LLMs act on conversational context that changes with each turn. That means policy decisions based only on static rules or content patterns will miss the real boundary where misuse happens. The practical conclusion is that governance must observe runtime context, not just data content.

LLM runtime behaviour belongs in the same governance conversation as NHI controls. Once models can call tools, access internal systems, or participate in workflows, the question becomes who or what is acting on behalf of the organisation. That pushes LLM security into identity governance, entitlement review, and access monitoring territory. Practitioners should align LLM oversight with broader machine identity controls, not leave it to point security tools.

Multi-layer defence matters because no single control class covers conversational abuse. The article correctly shows that browser tools, DLP, and DSPM each fail in different places. That pattern reinforces a broader identity lesson: control design must follow the behaviour of the actor, not the label on the platform. Security teams should build layered oversight around discovery, context, and execution separately.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That governance gap aligns with OWASP Agentic AI Top 10 guidance on tool misuse and context poisoning, which practitioners should map to runtime monitoring.

What this signals

LLM governance is converging with broader agent oversight. The same blind spots that make agent access hard to audit also apply when LLMs are embedded into workflows and toolchains. Practitioners should expect discovery, logging, and access review to become cross-functional controls spanning AI, IAM, and security operations, not isolated experiments.

Context-aware control design will define the next phase of LLM security. Static inspection is not enough when the risk is shaped by prompt history, model output, and downstream execution. Security teams that already align identity controls with runtime behaviour will be better placed to govern these systems as they move from chat interfaces into operational workflows.

For practitioners

• Map all LLM entry points Inventory direct chat use, embedded copilots, vendor apps, and API-connected models so Shadow AI does not remain outside policy, logging, and review.
• Instrument prompt and tool-call logging Capture prompts, responses, and connected tool actions together so investigators can reconstruct context and see where model execution crosses into internal systems.
• Extend DLP beyond outbound inspection Tune controls for incremental disclosure, prompt injection, and risky inbound content entering developer and analyst workflows, not only outbound exfiltration.
• Classify LLMs by access path and data exposure Group models by web, API, and embedded access patterns, then assign governance based on the data they can reach and the systems they can influence.

Key takeaways

• Traditional security tools fail on LLMs because the threat surface is conversational, contextual, and often invisible to controls built for static web and data flows.
• The operational evidence in the article is that browser security, DLP, and DSPM each break at a different point, so no single control class can cover model risk end to end.
• Practitioners should shift from point controls to discovery, context logging, and access governance if they want a credible LLM security programme.

Key terms

• Shadow AI: Unmanaged or undiscovered AI use inside an organisation. It includes direct chatbot access, embedded assistants, and API-connected models that operate outside approved governance, logging, or review. The main risk is not only data leakage, but untracked access and unaccountable behaviour.
• Prompt Injection: A manipulation technique that causes an LLM to follow attacker-controlled instructions hidden in prompts, content, or retrieved data. It is dangerous because the model can treat untrusted text as operational guidance, leading to disclosure, policy bypass, or unsafe tool actions.
• Contextual Security Control: A control that evaluates meaning, intent, and session history instead of only matching fixed patterns. In LLM environments, contextual control is essential because risk can emerge over multiple turns, through indirect prompting, or when the model acts on information that static tools cannot interpret.
• LLM Runtime Governance: The set of policies and controls that monitor what a model can see, say, and trigger while it is in use. It extends beyond storage or perimeter controls and focuses on live prompts, tool calls, and downstream actions that can affect internal systems or data.

Deepen your knowledge

LLM governance and Shadow AI discovery are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for model use in a similar environment, it is worth exploring.

This post draws on content published by Lasso Security: Can Common Cyber Security Tools Handle Large Language Model Risks? Read the original.