Security risks when deploying an LLM into company processes

The main security risks when deploying an LLM into company processes are leakage of sensitive data through external APIs, prompt injection attacks, unauthorised access to information through poorly separated data, and uncontrolled agent actions in connected systems. Most of these do not come from the model itself but from the architecture around it: how the model is connected to company data, what tools it holds, and who can see its output. A properly designed architecture eliminates most of these risks at the design stage rather than through patches afterwards.

Data leakage through external APIs

If a company sends sensitive data to a public API without further guarantees, that data leaves the controlled environment. With some providers there is a risk it will be used for further training of the model or retained longer than the company expects.

What to do. Enterprise agreements that guarantee data is not used for training, or an on-premise or EU-hosted deployment for the most sensitive use cases.

Prompt injection

An attacker plants malicious instructions directly in the input data — in an email, a document or a web page the agent processes — to push the system off its original task: to disclose internal information or take an unauthorised action.

What to do. Strict separation of system instructions from input data, validation of output before any action is taken, and restricting the agent's permissions to the minimum the task requires.

Insufficient separation of access rights

If the system works with data from several departments, clients or sensitivity levels without proper filtering, a user with lower permissions can receive an answer built on data they were never meant to see.

What to do. Metadata filtering at the retrieval layer, not only in the application, and rigorous isolation testing before go-live. What this looks like with several clients in one system is covered in the multi-tenant vector database.

Uncontrolled agent actions

With agents that have access to real systems — CRM, ERP, email, payments — a wrong decision is a real risk: sending incorrect information to a client, a faulty record update, or an action outside the intended scope.

What to do. Clearly defined permission boundaries, mandatory human approval for sensitive actions such as payments or contractual commitments, and continuous monitoring of what was carried out.

Hallucination in critical processes

A model can produce a factually wrong answer with high confidence. In processes such as compliance, legal advice or financial decisions, that kind of error can have serious consequences.

What to do. A RAG architecture pointing at a verifiable source document instead of relying on the model's general knowledge, plus a clear marker for where human review is required.

A missing audit trail

Without a record of what the system did, on what data and why, it is impossible to investigate an incident afterwards or to demonstrate compliance under inspection.

What to do. Log every input, output and action taken, retained in line with internal and regulatory requirements.

Summary

Treating security as a design question

Security is not added after go-live. The most effective companies address these risks during architectural design:

• Least privilege – the model or agent gets access only to the data and tools the task genuinely requires.
• Segmentation by sensitivity – the most sensitive processes may warrant a stricter deployment than the rest.
• Pre-deployment testing – simulated attacks including prompt injection, and verification of data isolation before production.
• Continuous monitoring – security is not a one-off check but part of running the system.

Most incidents with AI systems are not a failure of the model. They are a failure of permissions.

GDPR and the EU AI Act

Deploying in the EU means these security risks overlap with legal obligations. GDPR requires a clear basis for processing personal data and the ability to demonstrate where and how data is processed. The EU AI Act adds requirements on transparency and risk management for systems classified as high risk, which can include some kinds of company agents in sensitive sectors: healthcare, finance and decisions about people.