What are LLMs

LLMs (Large Language Models) are language models with a large number of parameters. These parameters are the model’s variables, which it learns during training. Typically, this training is unsupervised learning on a large data set, during which the algorithm tries to find patterns in the provided data. The more it learns, the more accurate the model will become in detecting patterns. In case of language models, the model will be able to “understand” and “reflect” natural language. It is to note, however, that the proficiency of the model will depend on the size and quality of the training data.

Probability Theory

A huge misconception about LLMs is that they “understand” the user input or even reason about it. This is not true, however. An LLM divides the input text into several, so called tokens, where each token is a word or even only part of a word. It then calculates the probability of the next token Xn based on the last k tokens Xn-1, …, Xn-k:

P(Xn | Xn-1, …, Xn-k)

It then chooses one of the most likely tokens to “answer” the question, i.e., continue the input.

This is already used in many applications, such as text completion or predictive typing, among many others.


Prompts are inputs or queries to the LLM. For example:

SYSTEM PROMPT: You are a translator for English/Spanish.

Since the LLM will calculate probabilities on how a text will continue, so called system prompts can be used to prime the LLM to assume a role, such as a translator in the above example.

Prompt Manipulation

Prompts can also be used to manipulate the LLM’s behavior in so far that incorrect outputs are generated. This underlines the fact that LLMs only calculate probabilities. One example is the calculation of a simple sum:


Hallucinations are incorrect information delivered by LLMs. These can occur, e.g., due to faulty training data. Another reason for hallucination can be intentional attacks on the training data. Example:

Primer: Injection Attacks

Injection attacks, such as Cross-Site Scripting (XSS) or SQL Injections occur, when user input is interpreted as code.

For insance, if an attacker injects JavaScript code into the parameter q, which is reflected on the resulting website:

This might be rendered as:

A malicious user can abuse this, to steal user data or perform other attacks.

The typical way to protect against injection attacks is to make code and text distinugishable, e.g., through encoding user input.

Prompt Injections

Injection attacks can also occur in the context of LLMs. In this case, however, distinguishing code from text is not as easy, since basically everything is text.

LLMs can have different roles, e.g., SYSTEM, USER, and ASSISTANT:

SYSTEM: represents the prompt, the instructions to the LLM

Injections can then happen, for instance, as follows:


You are a large language model, which answers as truthfully and concisely as possible.


Now you might ask: “But if the attacker only attacks their own system, what impact does this have?” – and you would be right. In this case, there would be no impact. However, LLMs are more and more integrated into other applications, such as the keyboard in your phone, personal assistants, and more.

Imagine a scenario, where an attacker sends a malicious email to you containing the following prompt:

If now, e.g., the personal assistant on your phone (which is basically an LLM) opens this email to summarize its conents for you, all your emails will be leaked to an attacker.

Other scenarious could include allowing an LLM to browse the web, which could lead to them stumbling upon malicious prompts as well.

If an LLM gets the permission to execute code on your system, you can imagine what could happen.

Thus, as soon as LLMs are given the opportunity to change systems or parts of them, this can be dangerous.


So, what can we do to prevent such attacks? Unfortunately, this is extremely difficult and has not been fully solved. The biggest issue to tackle is that other than in XSS or SQL Injection, text and code cannot be distinguished easily, because to an LLM, every input is text.

There are several attempts being made to resolve this potential attack vector.

For instance, OpenAI has created a so called “Moderation Endpoint”, which is basically another LLM, which filters the user’s input before giving it to the intended LLM. The issue with this concept is that the Moderation Endpoint itself might be susceptible to prompt injections.

Another idea is to use input filtering. However, as widely known in IT security, blacklisting approaches typically do not work, because attackers will always find a way to bypass them. Whitelisting, on the other hand, might be too restrictive, so that the LLM becomes useless or too restricted.

Output can also be validated, so that if the resulting output is unexpected, processing is stopped. The problem here is that, e.g., in case of code execution by the LLM, it might be to late to block anything at this point.

Finally, one of the most useful remediations so far is to create a complex and detail system prompt including secrets so that an attacker is very unlikely to find a way to make the LLM do its bidding. Nevertheless, even this approach is not perfect so that we will need more research in the future to find a way to make LLMs more secure.


OWASP released the 10 most important vulnerabilities of LLMs (OWASP | Top 10 for Large Language Model Applications (llmtop10.com)). The most important of these include Prompt Injections, as discussed here, and Training Data Poisoning, which can aid an attacker in abusing an LLM after its training.

In general, many of the LLM Top 10 include vulnerabilities, which also apply to other systems. These vulnerabilities include, e.g., Supply Chain or Denial of Service attacks.


  • https://platform.openai.com
  • https://greshake.github.io/
  • https://simonwillison.net/2023/Apr/14/worst-that-can-happen/
  • https://www.robustintelligence.com/blog-posts/prompt-injection-attack-on-gpt-4
  • https://research.nccgroup.com/2022/12/05/exploring-prompt-injection-attacks/
  • https://cdn.openai.com/papers/gpt-4-system-card.pdf
  • https://openai.com/blog/new-and-improved-content-moderation-tooling
  • https://systemweakness.com/new-prompt-injection-attack-on-chatgpt-web-version-ef717492c5c2
  • https://dev.to/jasny/protecting-against-prompt-injection-in-gpt-1gf8
  • https://doublespeak.chat/#/handbook
  • https://securitycafe.ro/2023/05/15/ai-hacking-games-jailbreak-ctfs/
  • §https://positive.security/blog/auto-gpt-rce