LLM security vs. LLM protection: where runtime control matters

At a glance

What this is: This analysis separates LLM security from LLM protection and shows that the first is a governance layer while the second is the inline enforcement layer that can interrupt attacks during execution.

Why it matters: IAM, AI security, and application teams need that distinction because access policy, logging, and static filters do not stop session-level abuse when an LLM application is already running.

Context

LLM security problems appear when teams assume that authentication, policy checks, and logging are enough to protect a production model. In practice, those controls shape posture and visibility, but they do not stop malicious behaviour once a session is live. The key governance gap is the difference between controlling access to an LLM and controlling what happens during execution.

This article is about that runtime gap in AI security. It is especially relevant where LLM applications depend on API keys, retrieval-augmented generation, tool use, and output handling, because each of those creates an identity and enforcement boundary that static controls cannot fully police on their own.

Key questions

Q: How should teams decide whether they need LLM security or runtime protection first?

A: Start with LLM security when the gap is governance, access, logging, or configuration hygiene. Prioritise runtime protection when production sessions are already exposed to prompt injection, jailbreaks, or unsafe output handling. In practice, the first layer reduces exposure and the second layer stops live abuse. Mature programmes need both, but they solve different problems.

Q: Why do static LLM controls fail against indirect prompt injection?

A: Because the malicious instruction often enters through trusted retrieved content or a legitimate data source rather than the prompt itself. Static boundary checks can miss it, while the harmful behaviour only becomes clear later in the session. That is why runtime correlation matters more than individual-message scanning.

Q: What are the signs that an LLM protection layer is not actually enforcing policy?

A: A weak protection layer can log risky prompts, flag suspicious content, or expose configuration issues, yet still allow the model to complete the harmful action. If it cannot correlate prompt history, tool calls, retrieved content, and output sequence, it is probably detecting risk rather than enforcing policy. That is a measurement problem, not just a tooling problem.

Q: When should LLM runtime controls be treated as part of identity governance?

A: When model access depends on API keys, service accounts, workload identities, or delegated tool permissions, runtime control becomes an identity governance issue. The relevant question is not only who logged in, but which machine or application identity can invoke the model and what it can reach afterwards. That is where LLM security overlaps with NHI discipline.

Technical breakdown

What LLM security actually covers

LLM security is the governance layer around a model application. It includes authentication, access control, static policy enforcement, audit logging, posture scanning, prompt injection detection, and output filtering. These controls answer who can call the model, what the application is allowed to do, and what evidence is left behind. They are strongest before execution starts and weakest once behaviour becomes dynamic across a live session.

Practical implication: Use this layer to reduce exposure and improve auditability, but do not expect it to stop an attack already in motion.

Why runtime protection is different from prompt filtering

LLM protection sits inside the request-response path and evaluates behaviour while the session is unfolding. That matters because many attacks do not look dangerous at the single-prompt level. Indirect prompt injection may arrive through retrieved content, and multi-turn jailbreaks may only become visible when the full conversation is correlated. Runtime enforcement can interrupt those sequences before the model completes the harmful action.

Practical implication: Design controls that inspect full-session context, not just isolated prompts, if you need real enforcement rather than after-the-fact detection.

Where retrieval-augmented generation changes the control problem

RAG complicates the boundary because the malicious instruction may enter through a legitimate retrieval channel instead of user input. Static prompt scanners cannot reliably distinguish a harmless document from one that contains an embedded instruction intended for the model. That means the application now has to govern both the identity of the calling user and the trustworthiness of retrieved content, output, and tool calls.

Practical implication: Treat retrieval sources, tool outputs, and generated responses as enforcement points, not just model inputs.

Threat narrative

Attacker objective: The attacker wants the model to carry out an unsafe action or expose information while appearing to operate within normal session behaviour.

1. Entry occurs when an attacker places an instruction inside retrieved content, a web page, or another legitimate data source that a RAG pipeline can fetch.
2. Credentialed access and prompt validation do not stop the payload because the content enters through an authorised channel and looks benign at the individual-message level.
3. The model follows the embedded instruction across the session, allowing the attack to unfold in a coordinated sequence that static detection cannot see in real time.
4. Impact occurs when the model leaks data, executes an unsafe action, or reflects hostile instructions into downstream workflows.

Breaches seen in the wild

• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.
• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

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

LLM security is a posture layer, not an enforcement layer. Access control, logging, configuration hygiene, and output filtering all matter, but they answer different questions from the one defenders care about during live exploitation. Once a model session is under way, the decisive control is the ability to interrupt behaviour, not merely document it. Practitioners should treat governance and runtime enforcement as separate controls with separate failure modes.

Runtime context is the real security boundary for production LLMs. The article is right to centre full-session correlation, because a single prompt rarely tells the whole story. What matters is whether the system can inspect prompt history, tool calls, retrieved content, and output sequence together. That is where AI security moves from policy to control effectiveness.

Indirect prompt injection is a governance trust-gap problem, not just a filtering problem. The named concept here is the runtime enforcement gap: static controls can describe acceptable behaviour, but they cannot reliably stop behaviour that emerges only across a session. That gap becomes sharper when retrieval and tool use are present, because trust is being delegated to content the caller did not author. Practitioners should govern the trust boundary, not just the model endpoint.

Identity controls for LLMs have to extend beyond human login to workload and API identity. The article makes clear that API key governance and identity-based access policies are part of the baseline, but they are not enough on their own. In production, the more important question is which application, service, or agent identity can invoke the model, at what rate, and with what downstream permissions. Security teams should align LLM governance with machine identity discipline, not only user access.

The market is moving toward converged governance plus enforcement, but the category split still matters. Vendors may package detection, posture, and runtime blocking under the same label, yet the operational question remains unchanged: can the control stop a session-level attack before the model acts? Teams should evaluate products against that boundary, because naming does not change capability.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Runtime enforcement is becoming the real dividing line in AI security. Teams that stop at access policy and logging will continue to miss attacks that unfold inside the session, especially when retrieval and tool use are involved. The practical shift is toward controls that inspect behaviour at execution time rather than only at the perimeter.

LLM governance now has a machine-identity dimension. API keys, service accounts, and delegated application identities are part of the attack surface, not just administrative plumbing. Programmes that already manage NHI risk should extend that discipline to model invocation, retrieval channels, and downstream tool permissions.

For practitioners

• Separate posture controls from runtime enforcement Map which controls govern access, configuration, and audit, then identify which control actually blocks behaviour mid-session. If a tool only records or flags an event after the fact, it belongs in your governance stack, not your protection stack.
• Inventory every LLM trust boundary Document the identity of each caller, the API keys in use, retrieved sources, tool integrations, and output destinations. Treat each one as a distinct enforcement point because a single application can fail through several different channels.
• Test for indirect prompt injection across RAG flows Run controlled tests where malicious instructions are embedded in retrieved documents or pages rather than in the user prompt. Verify whether the system can recognise the attack only after the model has already acted.
• Require session-level correlation before approval Assess whether your monitoring can connect prompts, tool calls, retrieved content, and output history into one view. If it cannot, then it will miss the multi-turn patterns that distinguish legitimate use from coordinated exploitation.

Key takeaways

• LLM security reduces exposure through access control, logging, configuration hygiene, and static policy, but it does not stop a live attack once execution begins.
• Runtime protection is the control that can interrupt prompt injection, jailbreak progression, and unsafe output handling while the session is still active.
• Production LLM governance now needs both identity discipline and behavioural enforcement because the attack surface spans API keys, retrieval paths, and tool calls.

Key terms

• LLM Security Framework: A structured set of controls for governing large language models across their lifecycle. It defines how access, data handling, execution, and monitoring should work together so AI systems are not secured piecemeal. In practice, it creates a common baseline for policy, oversight, and accountability.
• LLM Protection: The runtime enforcement layer that inspects model behaviour as it happens and blocks unsafe actions before they complete. It is designed to intervene during execution, not just record or detect suspicious activity after the fact.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Retrieval-augmented Generation: Retrieval-augmented generation is a pattern where an AI model pulls external information before generating output. The security challenge is that access rules can weaken when data is chunked, embedded, cached, or reused, so source permissions may not automatically follow the content into the model's context.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity controls to the broader governance challenges that production AI systems create.