The best known list of LLM security risks has ten items. You decide three of them inside your own company. On the other seven you are a spectator.
Of the two, that is the more useful message. As long as the list is read as a specification, you end up with a security project nobody in the company can run, plus a budget line for a tool that does nothing about seven of the ten items.
The list of LLM security risks was not written for you
The list in question is the OWASP Top 10 for LLM Applications, 2025 edition, maintained by the OWASP GenAI Security Project. OWASP states in its opening sentence who the collection is for: risks and mitigations for developing and securing generative AI and large language model applications, across the development, deployment and management lifecycle. None of those activities happens in a company that subscribes to Microsoft 365 and adds an assistant to it.
Three of the ten items show this immediately: Data and Model Poisoning, System Prompt Leakage, Vector and Embedding Weaknesses. In most SMEs nobody trains a model, and there is no hand written system prompt for anyone to steal.
Sort the LLM security risks for a company that buys AI rather than builds it, and this is the picture: three items you decide in daily operations, three at purchase, three belong to the vendor. That leaves number one, Prompt Injection. We took that one apart separately, and the finding there was that prompt injection is a permissions question for you, not a model question. Which puts it with the second of the three decisions that are yours.
What goes in, and what the assistant may read on its own
Sensitive Information Disclosure sits at number two. OWASP lists what it means: personal data, financial details, health records, confidential business data, credentials, legal documents. Addressed to the user side, it says that consumers need to understand the risk of unintentionally providing sensitive data that may later be disclosed in the model's output.
This item has two halves. Hardly any vendor conversation covers the second one.
The first half is what employees type in. Most rollouts talk about this half, and a data classification plus a company account largely settles it. Which categories may go into an AI tool and which may not is something we worked through in which company data belongs in ChatGPT.
The second half is what the assistant may read on its own. An assistant built into your Microsoft 365 gets no new rights. It uses the ones the signed in person already has. If a drive has been open to everyone for years, that was a housekeeping problem nobody noticed. Now it is a housekeeping problem with a search function that answers politely.
The countermeasure OWASP names here is nothing exotic. It is least privilege: access only to the data a given person or process needs. That recommendation sounds unremarkable. In our experience it achieves more than a purchased tool. For the walkthrough before a Copilot rollout, we wrote it up in permissions before the Copilot rollout.
Both halves are an access question, and no model vendor can answer it for you.
What it may do without asking
Excessive Agency, number six, is defined by OWASP as the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated output from a model. The list names three root causes: excessive functionality, excessive permissions, excessive autonomy.
The word "manipulated" brings number one back in. Whether the model hallucinated or someone fed it instructions through injected text makes no difference to the damage. What limits the damage is your answer to what the assistant may do without asking. OWASP recommends in so many words putting a human in the loop to approve high impact actions before they happen, and gives as an example of excessive rights a read task granted the ability to change and delete as well, when reading was all that was needed.
The moment an assistant gets a connector that can write, this stops being an AI question. It is the same question as for any service account: who approved it, with which rights, and until when. That last part is missing in many companies. An approval without an expiry date rarely gets reviewed, and in our experience that is exactly where rights accumulate that nobody can justify any more.
How deep the review before an approval has to go is something we graded in evaluating AI tools. For tools that chain several steps together on their own, what we wrote on governing AI agents applies on top.
What you do with the answer
Misinformation sits at number nine, and this one cannot be purchased away. OWASP describes the core as overreliance: users place excessive trust in the output and fail to verify its accuracy.
The countermeasures OWASP names for it are organisational: cross check output against trusted external sources, build in human oversight and fact checking for critical content, communicate limits and risks clearly to users. Plus a sentence that rarely gets quoted: the people doing the checking also need training, so they do not become reliant on the AI themselves.
For an SME this turns into an operational question. It reads: where does a wrong answer cost money or trust? A quotation, a costing, a contract clause, a payroll run, a data protection answer to a customer written out of a chat window. At those points there was a four eyes principle before AI came along, or there should have been. The assistant only makes its absence visible faster.
This item requires no investment. It requires you to name three or four points where an answer does not go out unchecked.
Three items that hang on the purchase
Three further LLM security risks are settled in the purchasing conversation, and rarely looked at again afterwards.
Supply Chain, number three, is the most tangible of them. OWASP recommends carefully vetting data sources and suppliers, terms and conditions and privacy policies included, and using only trusted suppliers. Along with the clause that marks the limit of that review: models are binary black boxes, and unlike open source, static inspection offers little in the way of security assurance. Swiss law points the same way, only more bindingly. Art. 9 para. 2 of the Data Protection Act states that the controller must in particular satisfy itself that the processor is able to guarantee data security. Satisfy itself, not merely agree it in writing. And para. 3 requires prior approval before a processor passes the work to a third party, which is where AI vendors with long subprocessor chains get uncomfortable. We described the walkthrough in the data processing agreement check for AI tools.
Vector and Embedding Weaknesses, number eight, affects you only when the assistant works on your own documents. Which is exactly what the assistants in the office suites do. OWASP describes the risk as content leaking between users or queries in shared environments, and recommends a permission aware vector store. The engineering for that sits with the vendor. What is left for you is a single question in the purchasing conversation: does the index honour the permissions that apply in our system? If no clear answer comes back, you have a piece of information worth more than a certificate in the appendix.
Unbounded Consumption, number ten, needs careful reading. OWASP writes it from the provider's point of view: an attacker triggers a high volume of queries and drives the cost of the service to unsustainable levels. It only becomes yours when you pay per use rather than per user per month. Then it is a billing question, and the countermeasure is in the list too: rate limits and quotas. On a per seat subscription you can tick this one off.
The vendor's construction site
Data and Model Poisoning, Improper Output Handling and System Prompt Leakage are construction work. Whoever trains the model, writes the application and sets the system prompt owns them. In a company that buys AI, there is no sensible work order to be written here.
One exception is becoming more common. Improper Output Handling means model output lands unchecked somewhere that it triggers something. As soon as someone in your company builds a flow where a model answer starts an action, in a low code tool, a macro, a script, this item has arrived with you. At which point it is what it always was: unchecked input that gets executed.
Out of this comes a list of things to skip, and it protects a budget. For these three LLM security risks an SME needs no dedicated AI security product. A purchased tool promising to prevent model poisoning or prompt theft defends a construction site that is not yours. The same goes for the forty item vendor questionnaire that answers none of the three decisions that sit with you. The money is better spent on the review of access rights you need anyway, and often the function you want is already in a subscription you have long been paying for. We describe that pattern in more detail under consolidating security tools.
The rest is a question for the vendor
Put the three decisions that fall inside your company side by side, and none of them is about the model. They are about access, about approvals, and about who stands behind an answer. You would have had to ask these questions even if nobody had ever built a language model. AI did not invent them, it only made them urgent.
That is also why an AI policy that starts with the tools so often runs on empty. One that starts with these three decisions is more useful. We have written up what belongs on a single page AI policy, and in AI governance and safe AI adoption we support exactly this part. If you want a sober read on where your company stands on its LLM security risks, an initial conversation is free of obligation.
Who in your company is allowed to grant an AI tool write access?
Frequently asked questions
What is the OWASP Top 10 for LLM Applications?
The OWASP Top 10 for LLM Applications is a list of the ten most significant security risks in applications built on large language models, maintained by the OWASP GenAI Security Project. OWASP states that the 2025 edition addresses those who develop, deploy and operate such applications, not companies that merely use them.
Which LLM security risks can an SME actually influence?
Three of them. First, which data goes in and what the assistant may read on its own. Second, which actions it may take without human approval. Third, what happens to the answer, meaning where unchecked output costs money or trust. All three are access and approval questions rather than model questions.
Does an SME need a dedicated AI security product?
In most cases no. Risks such as model poisoning, improper output handling and system prompt leakage sit with the vendor building the application. A purchased tool defends someone else's construction site there. A review of existing access rights achieves more, often using functions already included in the current subscription.
