LLM security hinges on runtime controls, not static policy

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Cyera's blog post: Under OWASP's 2025 LLM Top Ten, LLM risk is driven by runtime behaviour, not just pre-deployment policy.

Why it matters: IAM, security, and governance teams need runtime enforcement because LLM-backed services can expose data, accept malicious prompts, and exceed intended action scope after deployment.

By the numbers:

• 86 percent of respondents say they’re concerned about AI leaking sensitive data, and two-thirds have already discovered AI tools accessing data they didn’t need.
• Three quarters of respondents say autonomous agents are the hardest AI tools to secure, but only 14 percent have real-time rogue agent detection, and only 11 percent have implemented automated blocking.

Context

LLM security is no longer just a policy question. Once a model is connected to enterprise data, prompts, plugins, outputs, and downstream automations, the control problem becomes runtime governance: what the system can see, what it can say, and what it can trigger after deployment.

Cyera’s article frames that shift through the OWASP 2025 LLM Top Ten. The central issue for identity and access teams is that LLM-backed services do not stay inside static approval boundaries, so controls designed for pre-approved behaviour fail to contain real production risk.

That makes the article relevant to both AI governance and identity governance. The practical question is not whether an organisation has a policy for LLM use, but whether it can enforce least exposure, constrain actions, and detect misuse continuously across the model lifecycle.

Key questions

Q: How should teams govern LLMs that can initiate actions as well as generate text?

A: Treat action authority as a separate control plane from model output. Limit tool access, require approval for higher-risk operations, and log every initiated action so security and IAM teams can trace what the system actually did, not only what it said.

Q: Why do static policies fail to secure production LLMs?

A: Because the most important risk appears after deployment, when prompts, outputs, connected tools, and data flows interact in real time. Policies can describe expected behaviour, but they cannot intercept a harmful output or a risky tool call unless enforcement exists at runtime.

Q: What are the signs that an LLM is being misused or manipulated?

A: Common signs include unexpected completions, sudden shifts in tone, policy violations, and outputs that break normal guardrails or reveal rule-bending behavior. Teams should also watch for requests that appear to steer the model toward privileged actions, data access, or workflow changes. The most useful signal is behavior that diverges from the model’s normal pattern under similar conditions.

Q: How do runtime controls change the way security teams should measure LLM governance?

A: Measure whether the organisation can see, block, and redact risky behaviour in production, not just whether a policy exists. If dangerous prompts, outputs, or actions still move through the system, the governance model is not working.

Technical breakdown

Prompt injection and instruction separation

Prompt injection occurs when untrusted text manipulates an LLM into ignoring system instructions or revealing data. The technical failure is not limited to obvious user prompts. Indirect injection can arrive through embedded content, retrieved context, or downstream inputs that the model treats as authoritative. This is why system and user content must stay segmented at runtime, not just documented in policy. For security teams, the core architectural problem is trust boundary collapse inside the prompt stack. Once untrusted content can influence control instructions, the model’s effective behaviour is no longer limited by the original governance intent.

Practical implication: enforce runtime separation between trusted instructions and untrusted content before prompt data reaches the model.

Excessive agency in LLM-backed services

Excessive agency appears when an LLM can schedule work, invoke tools, or modify systems beyond the narrow intent of the request. That is a privilege problem as much as a model problem. The article’s emphasis on least-privilege rules, policy-based approval, and human review shows that broad action scope turns a model into an execution surface. In practice, the dangerous condition is not that the model reasons well, but that it can initiate consequences without a fresh authorisation decision for each action. That changes the security boundary from model output quality to action authority and revocation speed.

Practical implication: constrain model-initiated actions to the minimum authority needed and require approval for elevated operations.

Runtime protection for disclosure and misuse

Runtime protection sits between the model and the outside world, where it can inspect outputs, block unsafe calls, and redact sensitive data before leakage occurs. This matters because training-time controls do not catch everything that happens after deployment, especially when models generate code, summaries, or responses that feed other systems. The article’s use of AI runtime protection and DLP reflects a broader architectural pattern: security decisions have to be made at the point of emission, not only at the point of design. That is where disclosure, misuse, and unbounded consumption become operationally visible.

Practical implication: place enforcement at output and tool-use boundaries so risky behaviour is intercepted before it leaves the model.

NHI Mgmt Group analysis

Static policy is the wrong control plane for production LLMs. Policy describes intent, but LLM risk is expressed in runtime behaviour: what the model ingests, reveals, and executes after deployment. That makes continuous enforcement the real governance layer, not the policy document itself. Practitioners should treat policy as necessary but insufficient.

LLM governance now overlaps with identity governance because authority is becoming action-shaped. The article’s emphasis on excessive agency shows that the important question is not only who may authenticate to the system, but what the system itself is allowed to initiate. That shifts control design toward scoped action authority, approval gates, and continuous revocation at the point of use. Security teams need to govern permissions as runtime behaviour, not static entitlement.

Prompt injection exposes a boundary failure, not just a content-safety issue. The real weakness is the assumption that system instructions stay separable from untrusted inputs throughout the interaction. Once that assumption fails, the model can be steered into disclosure or misuse even when the surrounding policy looks sound. The implication is that trust segmentation must exist inside the operating path, not only in documentation.

Continuous visibility becomes the differentiator between AI adoption and AI sprawl. Cyera’s framing shows that organisations need inventory, observation, and blocking across prompts, outputs, and connected tools if they want to govern LLM use at scale. Without that, AI adoption quickly outpaces control coverage. Practitioners should assume that runtime blind spots will become governance blind spots.

LLM security is converging with broader data security operations. The article ties model safety to sensitive data protection, DLP, and misconfiguration monitoring rather than to a standalone AI stack. That is the right direction because the model is only one part of the data path. Teams should align AI governance with existing data security controls instead of building a parallel programme.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: AI Security Platform Buyer's Guide

What this signals

Runtime enforcement is becoming the real governance layer for LLMs. Policy documents still matter, but they do not stop prompt injection, disclosure, or excessive agency once the model is live. Teams need controls that can inspect inputs, outputs, and tool calls in the moment they occur, because that is where the security decision is actually made.

LLM programmes now sit inside broader identity and data security programmes. The model’s permissions, data exposure, and action scope are no longer separable from IAM and DLP. Security teams should expect LLM governance to converge with least privilege, sensitive data control, and continuous monitoring rather than remain a standalone AI initiative.

For practitioners

• Map LLM data flows end to end Inventory prompts, retrieval sources, embedded apps, outputs, and downstream systems so you can see where sensitive data and tool access actually move.
• Separate trusted instructions from untrusted content Design prompt handling so system instructions, user input, and retrieved context remain isolated and cannot overwrite one another at runtime.
• Restrict model-initiated actions Apply least-privilege boundaries to tool calls, scheduling, and system changes so the model can only initiate the actions it genuinely needs.
• Add runtime blocking and redaction Use enforcement that can stop risky outputs, redact sensitive fields, and halt suspicious requests before they reach external systems.

Key takeaways

• Cyera’s article argues that LLM security depends on runtime enforcement because static policy cannot reliably contain prompt injection, disclosure, and excessive agency in production.
• The source highlights a control gap that affects both data security and identity governance, especially when LLMs can access information or initiate actions they do not need.
• Security teams should focus on visibility, blocking, and action scoping at runtime if they want AI adoption without expanding the attack surface.

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.
• Runtime Protection: Runtime protection is a control model that observes application behavior while software is running and blocks unsafe actions as they occur. In Java estates, it helps distinguish active exploit paths from dormant vulnerable code, which is essential when patching is delayed or impossible.
• Excessive agency: A condition where an AI system is given more operational authority than its task requires. The risk is not just poor output. It is that mistakes, manipulation, or compromise can produce destructive actions at machine speed across the systems the agent can reach.
• AI Security Posture Management: A governance approach for discovering and tracking AI assets such as models, agents, datasets, vector stores, and related infrastructure. It becomes useful only when inventory is connected to runtime exposure and the identity that can actually reach the data.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or AI governance programme, it is worth exploring.