LLM & AI Application Security in the UK

CyberSecurity · United Kingdom

LLM and AI application security in the UK from 4hosting tests applications that call a language model at runtime, against the OWASP Top 10 for LLM applications: prompt injection, insecure output handling, sensitive data leakage through RAG, and excessive agent agency. We test access control on your retrieval layer, add guardrails and PII redaction, and run AI red teaming against your specific application, not a generic benchmark.

  • Tested against the OWASP Top 10 for LLM applications
  • RAG access-control testing, not just model-level checks
  • AI red teaming with promptfoo/garak against your application
  • OWASP Top 10 for LLM Applications
    Framework
  • 1–8 h/month on VPS; 5–10 h/month on dedicated servers depending on the plan; 10 h/month on GPU servers
    Included hours
  • EU AI Act awareness built into assessments
    Regulatory context
  • EUR, with UK VAT (20%) itemised on the invoice
    Billing
01

This is about the application, not the model

An application that calls an LLM has an attack surface distinct from the underlying model itself: prompt injection lets an attacker manipulate the model's behaviour through crafted input, insecure output handling means the model's response gets trusted and executed without validation, and excessive agency means an AI agent is given more permission to act — send emails, run queries, call APIs — than the task actually requires. These are OWASP Top 10 for LLM Applications categories, and they're application-design problems, not model problems.

  • Prompt injection: manipulating model behaviour via crafted input
  • Insecure output handling: trusting model output without validation
  • Excessive agency: an AI agent with more permission than the task needs
02

RAG access control and data leakage

Retrieval-augmented generation pulls context from a document store or database to ground the model's answers, but if access control on that retrieval layer doesn't match the requesting user's actual permissions, the model can surface data the user should never see — sometimes through an indirect, conversational path that bypasses a standard permission check entirely. We test whether retrieval respects the same access boundaries as the rest of your application, not just whether the model itself was fine-tuned to refuse obviously sensitive requests.

03

Guardrails, PII redaction and rate limits

Guardrails filter both input and output: catching attempted prompt injection before it reaches the model, and redacting personally identifiable information before a response leaves the system. Rate limits on model calls protect against both cost abuse and automated probing for weaknesses. We also review prompt logging practices, since logs containing user input and model output are themselves a data-handling surface under GDPR.

  • Input/output guardrails against prompt injection and unsafe output
  • PII redaction before responses leave the system
  • Rate limits against cost abuse and automated probing
04

AI red teaming and where the included hours go

We run structured AI red teaming with tools like promptfoo and garak against your specific application and prompts, not a generic model leaderboard test, since a guardrail that holds against a public benchmark can still fail against an attack crafted for your exact system prompt. This work, along with key and model security review, draws on the CyberSecurity hours in your plan — 1–8 hours a month on VPS, 5–10 on dedicated servers depending on the plan, 10 on GPU servers — requested from the client panel; hours don't roll over.

How we work

  1. Request from the panel

    Open a request under Services describing your LLM application: what model it calls, whether it uses RAG, and what agency it has.

  2. Map the attack surface

    We map prompt injection paths, RAG access boundaries and agent permissions against the OWASP Top 10 for LLM applications.

  3. Red-team and test

    We run structured red teaming against your application with promptfoo/garak-style tooling, confirming exploitability of each finding.

  4. Deliver guardrails and a report

    You receive a report with reproduction steps, plus recommended or implemented guardrails, PII redaction and rate-limit configuration.

Use cases

SaaS company adding a RAG-based support assistant

A London SaaS vendor building a customer-support assistant over its knowledge base gets RAG access-control testing, confirming the assistant can't surface one customer's data to another.

Fintech platform with an AI-assisted internal tool

A fintech company giving an internal AI agent access to query customer records gets an excessive-agency review, scoping the agent's permissions down to exactly what the task requires.

Public-facing chatbot handling sensitive queries

A company running a public-facing chatbot gets prompt-injection testing and PII redaction guardrails, ahead of a wider rollout that will handle more sensitive user queries.

Technology stack

  • promptfoo
  • garak
  • OWASP Top 10 for LLM Apps
  • Llama Guard
  • Presidio
  • Rate limiting
  • RAG access control

Every subscription includes monthly DevOps, CyberSecurity and Programming hours: 1 h from the cPanel Advanced plan up, 1–8 h on VPS, 5–10 h on dedicated servers depending on the plan, and 10 h on GPU servers. Hours are requested from your client panel, don't roll over to the next month, and anything above the quota is accepted and billed separately.

Frequently asked questions

  • What is prompt injection, in plain terms?

    It's crafting input — sometimes hidden inside a document the model retrieves via RAG, not just typed directly by a user — that manipulates the model into ignoring its instructions or taking an unintended action. It's the LLM-application equivalent of an injection attack against a traditional database query.

  • How is this different from AI Code Security & Supply Chain?

    AI Code Security & Supply Chain covers securing the code itself, including code written with AI coding assistants. LLM & AI Application Security covers applications that call an LLM at runtime — the risks are about how the application uses the model, not how the application's code was written.

  • What is 'excessive agency' and why does it matter?

    It's when an AI agent is granted more capability — sending emails, executing database queries, calling external APIs — than the task it performs actually requires. If the model is manipulated via prompt injection, excessive agency is what turns a manipulated response into a real-world action with consequences.

  • Does RAG access-control testing require access to our production data?

    No — testing is scoped against a representative or staging dataset that mirrors your real access-control structure, so we can confirm the retrieval layer respects permission boundaries without needing access to live customer data.

  • What does AI red teaming actually involve?

    Structured, adversarial testing against your specific application and system prompt using tools like promptfoo and garak — attempting prompt injection, jailbreak patterns and data-extraction attempts — rather than relying on a generic public model benchmark that doesn't reflect your actual configuration.

  • Is this relevant under the EU AI Act?

    Depending on how your application is classified, EU AI Act obligations may apply to risk assessment and documentation. We build awareness of those obligations into our assessment approach, though a full regulatory classification is a legal question outside the scope of a technical security review.

Building an application that calls an LLM?

Tell us how your application uses the model and we'll test it against the OWASP Top 10 for LLM applications using your included CyberSecurity hours.

Guides for UK businesses