LLM security tools still leave execution-layer risk uncovered

At a glance

What this is: This is Lakera’s review of 12 LLM security tools, and its central finding is that current controls focus heavily on prompt-level threats while execution-layer risk remains under-governed.

Why it matters: IAM, PAM, and NHI teams need to treat LLM security as an authorisation problem as well as a content-safety problem, because tool access and downstream actions can outpace model-output guardrails.

Context

LLM security tools are often evaluated as if the main problem were malicious prompts, toxic output, or model hallucination. That framing is too narrow when the system can retrieve data, call APIs, and take actions inside enterprise workflows. The governance gap is not in the model response alone, but in what the AI system is permitted to touch and trigger.

For identity and access teams, the issue sits at the boundary between AI safety and access control. Once an LLM can operate through tools, the security model needs to cover authorisation, scope, and execution context, not just input filtering. Lakera’s article is about that broader control problem, not simply about detection tooling.

Key questions

Q: How should teams govern LLM tool access in production?

A: Treat tool access as a privileged capability, not a default feature of the model. Every API call, data lookup, or workflow action should be mapped to a named owner, a permitted scope, and a clear approval path. If the model can change state, governance must apply before the action is executed, not after.

Q: Why do prompt filters fail as the main control for AI agents?

A: Prompt filters only address the input layer, while most business risk appears after the agent has access to tools and data. Once an agent can make downstream choices, the dangerous action may be fully valid from a prompt perspective and still unacceptable from a governance perspective. Control has to extend to actions, not just text.

Q: What are the signs that an AI system has an execution-layer problem?

A: Look for AI applications that can touch multiple back-end systems, change records, or trigger automations without a separate policy check. Another warning sign is when teams can describe prompt controls in detail but cannot explain who authorised each downstream action. That gap usually means the execution layer is under-governed.

Q: How should security teams decide where to red team an LLM application?

A: Start with the workflow boundaries that create real authority: retrieval, external tools, connectors, and any action the model can trigger. Then test how prompts can influence those paths. If the application includes agents or multi-step orchestration, add chained scenarios that exercise the full path from input to side effect.

Technical breakdown

Why prompt-level controls stop at the model boundary

Prompt injection filters, leakage detectors, and hallucination guards inspect what goes into or comes out of the model. They do not by themselves govern whether the surrounding application can execute a tool call, query a data source, or pass a decision into a workflow. That distinction matters because many LLM risks now emerge after inference, when the application translates text into action. In identity terms, the model may be safe enough, but the execution path is still unconstrained. The control boundary has to move outward from content moderation to action authorisation.

Practical implication: separate content-risk controls from execution permissions so that model output cannot directly imply system action.

Execution-layer risk in AI workflows

An execution layer is the part of an AI-enabled system that turns model output into operational behaviour, such as retrieving records, opening tickets, changing records, or invoking APIs. This is where tool access, API scope, and approval logic matter most. If the AI system can select a tool and trigger it based on conversational context, then the real security question is whether that action was authorised for that state of the workflow. Traditional DLP and prompt guards were not designed to police tool invocation chains, delegated access, or task-scoped authorisation decisions.

Practical implication: inventory every tool, API, and workflow the AI system can reach, then bind each one to explicit authorisation rules.

Why red teaming alone does not close the governance gap

Red teaming is useful for finding prompt attacks, unsafe completions, and brittle guardrails, but it is still a test activity rather than a standing control. It can show where an AI system is vulnerable, yet it does not define who owns access scope, what is permitted in production, or how the system should be constrained after deployment. That is why execution-layer governance must sit alongside testing. For agentic and workflow-connected LLMs, the security problem becomes one of ongoing permission design, not a one-time adversarial exercise.

Practical implication: use red teaming to validate assumptions, but enforce ongoing authorisation and observability controls in production.

Threat narrative

Attacker objective: The attacker wants to turn model influence into downstream system action, data access, or workflow abuse.

1. Entry occurs through a malicious or indirect prompt that influences the LLM’s output or decision path.
2. Escalation happens when the application converts that output into a tool call, data retrieval, or workflow action beyond the original user intent.
3. Impact follows when the AI system reaches data, systems, or processes it was never meant to control directly.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

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

Execution-layer control is the missing identity boundary in LLM security. The market has spent heavily on prompt injection, output filtering, and red teaming, but those controls stop at the model boundary. Once the system can invoke tools or move data, the relevant question becomes who or what authorised the action chain. Practitioners should treat tool invocation as an identity event, not just an AI event.

Prompt safety and system safety are not the same governance problem. A model can be resilient to malicious phrasing and still sit inside an over-broad execution path. That is why content moderation and DLP do not replace access governance, scoped delegation, or observability over runtime actions. The field needs to stop treating output quality as evidence of secure behaviour.

Tool access turns LLMs into governed actors, not passive interfaces. The moment a model can retrieve records, change state, or call APIs, it begins to resemble a non-human identity with delegated authority. That brings NHI governance concepts into the AI stack, including inventory, scope control, and offboarding. The practitioner lesson is that execution rights must be managed as tightly as any other privileged machine credential.

Red teaming finds failure, but governance decides exposure. Stress testing is useful for discovering weak prompts and brittle guardrails, yet it does not establish the production rule set that limits damage. The real governance task is to define where an AI system may act, what it may reach, and which actions must remain human-confirmed. Organisations that stop at testing will still have an ungoverned execution layer.

Runtime authorisation becomes the decisive control plane for agentic AI. Lakera’s article points to a broader category shift: the hardest problem is no longer whether the model can be fooled, but whether a fooled or overconfident system can do anything consequential. That is a control-plane issue, not a model-quality issue. Practitioners should expect AI governance to converge with NHI and PAM disciplines around action boundaries.

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.
• Read next: AI Agent Authorisation Guide

What this signals

Execution-layer governance is the next control frontier for AI-enabled systems. Teams that already manage prompt injection and output filtering still need a separate policy for tool calls, delegated actions, and state-changing workflows. In practice, the question is no longer whether the model was fooled, but whether the surrounding system was allowed to act on the model’s output.

LLM security is converging with identity governance. Once an AI system can invoke APIs or alter records, it behaves like a governed actor with scoped authority. That makes authorisation design, action logging, and offboarding part of the AI security stack, not optional add-ons.

For practitioners

• Map AI tool access paths Document every API, database, workflow, and external service an LLM-powered application can reach, then identify which actions are merely observable and which can change state.
• Separate model guardrails from action permissions Keep prompt injection detection, output moderation, and leakage controls distinct from the policies that allow tool calls or data retrieval.
• Require explicit authorisation for consequential actions Force approval or policy evaluation before any AI-driven change to records, accounts, tickets, or other high-impact enterprise objects.
• Log AI execution context end to end Capture the prompt, selected tool, target resource, identity context, and final action so investigators can reconstruct what the system actually did.
• Treat LLM red teaming as a control test, not a control Use adversarial testing to validate assumptions, then convert the findings into standing authorisation and monitoring rules for production.

Key takeaways

• LLM security tools are strongest where the risk is visible at the prompt or output layer, but the article argues that this still leaves execution authority under-governed.
• When an AI system can retrieve data or invoke tools, security teams need to manage what it is allowed to do, not only what it is allowed to say.
• The practical gap is an authorisation problem, which means identity governance and runtime control now matter as much as model-facing safeguards.

Key terms

• Execution Layer: The execution layer is the operational point where identity policy becomes system change. It is where approvals, provisioning, revocation, and session controls either complete successfully or fail in ways that create drift. For practitioners, this is where governance is proven, not merely documented.
• Tool Invocation: Tool invocation is an action where an AI agent calls an external system such as a database, API, or file service. Each invocation should be treated as an auditable identity action because it is the point where the agent can move data, trigger changes, or widen its reach across the environment.
• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Backend Execution Authority: The ability for an authenticated user action to influence server-side commands or internal control flow. In identity terms, this matters because a narrow permission can become a much larger privilege when the platform translates input into execution rather than mere data handling.

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 programme, it is worth exploring.