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.
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.
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.
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.
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.
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.
Open a request under Services describing your LLM application: what model it calls, whether it uses RAG, and what agency it has.
We map prompt injection paths, RAG access boundaries and agent permissions against the OWASP Top 10 for LLM applications.
We run structured red teaming against your application with promptfoo/garak-style tooling, confirming exploitability of each finding.
You receive a report with reproduction steps, plus recommended or implemented guardrails, PII redaction and rate-limit configuration.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.