LLM Security in 2026: Threats, Defences, and What to Verify

You must now treat externally controlled content as untrusted input, enforce access permissions outside the model layer, constrain what tools the system can invoke, and independently verify any output before it becomes an action in the real world.

An analysis of 29 August 2026 of prompt injection attacks and defences in enterprise LLM deployments argues that security depends not on model behaviour alone but on the complete application architecture surrounding it. A legal assistant combining user instructions with externally supplied documents, or a corporate agent drawing on email, search results, and database queries, faces risks that prompt-level safeguards cannot fully address. In our assessment, this shift from model-centric to system-centric security represents a material change in how organisations must design and verify AI workflows that handle sensitive information or perform consequential actions.

Why does externally controlled content pose a distinct risk?

Enterprise LLM systems derive much of their value from external information. A legal system processes contracts and evidence. A compliance assistant inspects policies and records. A retrieval-augmented system depends on information retrieved from another data store. The security challenge is to use that untrusted information without allowing it to obtain unintended control over the system.

Research on indirect prompt injection demonstrates this directly. When instructions are embedded in external material—a webpage, a file, an email—tested models have shown difficulty distinguishing informational context from actionable instructions. This is not a laboratory-only concern. CrowdStrike's 2026 Global Threat Report documents adversaries exploiting legitimate generative-AI tools at more than 90 organisations in 2025, injecting malicious prompts to generate commands used for credential and cryptocurrency theft.

What are the distinct forms of prompt injection you need to defend against?

• Direct prompt injection — an input supplied directly to the model alters its behaviour in an unintended way.
• Indirect prompt injection — instructions embedded in external material such as webpages, documents, or files are processed by the LLM as though they were authoritative.
• Multimodal prompt injection — malicious instructions embedded in images, scanned documents, or screenshots that are human-invisible but machine-readable.
• Prompt injection through tool outputs — instructions embedded in the responses returned by APIs or external systems that the model then processes.
• Retrieval-layer injection — poisoned or manipulated content in databases or retrieval-augmented generation repositories that the model accesses during execution.

Why does model-level control fail where access control succeeds?

A system prompt can establish expected behaviour and task boundaries. It is useful but should not be treated as an access-control mechanism. A model-level instruction may tell an agent not to send confidential information to unauthorised recipients. A stronger security control is for the application itself to determine whether the requested destination is authorised before executing the operation.

Prompt-level control asks the model to behave correctly. Authorisation-level control restricts what the system is capable of doing. The latter remains enforceable even if the model has been manipulated. When an LLM can retrieve documents, query databases, or invoke tools, security depends on enforcing privilege and least privilege at the retrieval and execution boundaries, not solely on whether the model correctly interprets an instruction.

SecureSQL research evaluated natural-language database interfaces across medical, legal, financial, and political domains. The best-performing tested model achieved 61.7% accuracy compared with 94% for humans in the benchmark. Prompt-injection and inference attacks significantly affected model performance. This demonstrates why an LLM should not itself be treated as the database authorisation mechanism. If a user does not have permission to read a record, the database or application architecture should enforce that restriction independently of what SQL the model proposes.

What controls must you be able to demonstrate?

1. Document every information source — record every location from which the AI system can obtain data, including user prompts, documents, email, websites, databases, retrieval repositories, images, API responses, and agent memory.
2. Record every operation the system can initiate — document which actions the AI system is permitted to perform, including sending messages, exporting files, updating records, querying databases, changing permissions, and invoking external APIs.
3. Validate permissions independently of model reasoning — do not allow an LLM-generated request to substitute for deterministic access control; if an action requires a particular permission, verify that permission outside the model.
4. Test indirect injection against the actual workflow — place controlled adversarial instructions in representative documents, webpages, and external content and test the complete path from input to execution, not only generic jailbreak prompts.
5. Maintain an audit trail of what the system received, proposed, verified, authorised, and executed — ensure that credentials can be revoked, workflows disabled, compromised sources isolated, and relevant evidence preserved for incident reconstruction.
6. Require human approval for high-risk actions — where an AI-generated action could disclose sensitive information, alter access, trigger a financial transaction, or have legal or clinical consequences, ensure the reviewer has sufficient context to understand the proposed action and its consequences.

How does verification differ from authorisation?

Verification addresses whether an answer is sufficiently supported by evidence to be relied upon. Authorisation determines whether an action is permitted. They solve different problems. Independent model review can provide a separate check on factual support, source quality, and unsupported statements. It should not be described as a replacement for prompt-injection defences, access control, or authorisation. If multiple models receive the same poisoned source material and operate within the same unsafe permission structure, agreement between those models does not make the workflow secure.

A mature LLM workflow can be designed around distinct control stages: trust classification of the information source, permission-aware retrieval, constrained model processing, output verification, deterministic authorisation, human approval where required, action execution, and audit recording. Combining all of those questions into a single prompt is weaker than enforcing independent controls where deterministic enforcement is possible.

Tooling can help you implement these controls—logging, access-management systems, and workflow orchestration platforms can carry much of the burden. What remains your own professional judgement is the threat model itself: which information sources matter, which actions carry consequential risk, and where human oversight is not optional but essential to accountability.