James Sherlow, Systems Engineering Director, EMEA, Cequence Security discusses securing LLMs (large language models) via their APIs against top ten threats.
The emergence of proprietary Generative AI-as-a-Service offerings this year has paved the way for the technology to be adopted within the enterprise. According to the report, Harnessing the value of generative AI, almost a quarter of big business is now using GenAI, up from six per cent in 2023. What’s more, 82pc of those questioned planned to deploy AI agents over the next three years to autonomously perform tasks from coding to email generation to data analysis.
It’s a significant leap from deploying a chat bot to trusting the technology to independently perform such tasks and one that will require governance and compliance to be in place. But how do you go about securing this technology to the point where it can be trusted in this way?
GenAI has to be considered from two perspectives when it comes to security: both how we prevent it from doing what it shouldn’t, namely accessing and abusing data within the enterprise, as well as how we can protect it from being attacked by malicious threat actors. In other words, we have to protect the technology from itself as well as from attackers.
The unique issues associated with Large Language Models (LLMs) are documented in the OWASP LLM Security Top 10 which was recently updated in November for 2025. A lot has been learnt during the two years since the original list was drawn up and the latest version reflects this, drawing upon contributions from across the globe.
New LLM threats
The Top 10 expands upon some terms, such as ‘Denial of Service’ which has now become ‘Unbounded Consumption’ to reflect the fact that LLMs can max out resources. There have been numerous reports of GenAI scraping bots harvesting data while failing to honour robots.txt files or “allow to scrape” lists, for instance, which can lead to increased infrastructure costs or customer friction. Over usage can also occur as a result of a misconfiguration, human error, application error, or malicious intent.
The ’Excessive agency’ has likewise been widened to accommodate agentic architectures and the use of autonomous AI which we mentioned earlier. These are associated with an elevated level of risk because these agents or plug-ins could be assigned excessive functionality, permissions or autonomy, each of which could result in the LLM being given more free reign than is desirable.
New additions to the list include ‘Vector and Embeddings’ to address the risks posed by Retrieval-Augmented Generation (RAG) and ‘System Prompt Leakage’ to reflect the fact prompts are not always secure.
Turning theory into practice
Recognising these issues and being able to practically test for them is, however, another thing entirely. This requires LLM applications to be put through their paces against each of the vulnerabilities. Using synthetic traffic it is possible to identify such issues prior to deployment. For instance, recent testing of several popular GenAI applications revealed indirect prompt injection vulnerabilities. While standard prompts did not yield a response, malicious prompts were able to extract additional information from the AI systems. Following testing, recommendations can be made to the developers who can then take the necessary corrective action before the application goes live.
Testing in this way needs to become an integral part of GenAI deployments but they’re only one facet of securing the technology. The primary method used to communicate with and between GenAI systems, from user prompts to model responses, are Application Programming Interfaces (APIs) and for that reason any conversation about GenAI and security must also focus on API security.
APIs are key to monitoring, governing and controlling the technology. By monitoring the traffic flows to and from GenAI systems in the API requests, it’s possible to identify if sensitive data is being returned in requests and responses to and from the model. This can ensure that the LLM is checked for data leakage, for instance, with policies set to look for specific data and to block requests.
Similarly, when it comes to ‘Unbounded Consumption’, API monitoring can track the usage of GenAI systems to see it becomes excessive. Rules and policies can also be put in place to meter usage according to set parameters.
What’s more, by looking at security at the API level, behaviour analytics can be used to determine when GenAI goes rogue. GenAI systems can be manipulated to launch attacks on other networks by acting as jump hosts for attackers, for instance, but by monitoring for anomalous behaviour in terms of how the system interacts with third party systems these attacks can be blocked. Behaviour analytics can also be used to observe user interactions to determine if a user is attempting to manipulate the system, such as through direct prompt injection.
Of course, in these scenarios, it’s the GenAI system that is being subverted and the API that is the constant. That isn’t always the case. APIs are not intrinsically secure and are also susceptible to abuse – in fact, OWASP has another Top 10 list specific to the threats posed to APIs which was updated last year. If those APIs are not monitored and secured, they can be discovered by an attacker and their functionality used to access the systems or other APIs they communicate with.
If we bring GenAI into the equation that problem is then magnified. Organisations typically already have hundreds if not thousands of APIs deployed across their infrastructure, many of which are unmanaged or may not have been decommissioned, rendering them effectively invisible. Attackers seek out these shadow APIs because they can carry out reconnaissance and abuse the API without fear of detection. GenAI will increase the speed with which attackers can both find and subvert those APIs.
Both APIs and the LLMs they connect with are open to abuse and have created a much wider attack surface necessitating the use of API protection. The symbiotic relationship between the two will be vital in enabling us to secure and control GenAI as it becomes more entrenched and more autonomous. Security mustn’t become an afterthought and needs to be addressed by adopting a holistic approach to application and API security.
