AI & LLM penetration testing.
An LLM in your product is a new, untrusted input into the systems that run your business — and, once it has tools, an actor with your users' privileges. We test what the model can do, not what it will say.
We secure the Czech tech companies that made it globally.
AI & LLM penetration testing
A language model wired into your product is not a chatbot bolted onto the side. It is a new input channel into the same systems your web application runs on — one that accepts natural language from anyone, reads documents and web pages you did not write, and increasingly calls tools and takes actions on a user's behalf. Everything the model produces is attacker-influenced input to whatever consumes it: your APIs, your database, your users' browsers, the next agent in the chain.
Most AI security tooling measures the model — how often it can be talked into breaking its own rules. That is not a security finding. A security finding is an agent that issues a refund it was not authorised to issue, a retrieval step that returns another tenant's documents, or a model answer rendered as HTML that runs script in the user's browser. Our AI & LLM penetration testing is aimed at the system around the model: what it can reach, on whose behalf, and whether the layer beneath it checks.
What we test
Prompt injection & hidden context exposure
Direct injection through user input and indirect injection through anything the model reads: uploaded documents, retrieved pages, emails, tool outputs, other agents. Multi-turn and encoded payloads, guardrail bypass, extraction of the system prompt and other hidden context (OWASP LLM01, LLM07).
Tools, agents & privilege
What the model is allowed to do, and on whose authority. Function-calling and MCP tool boundaries, excessive agency, confused-deputy paths where the agent holds more privilege than the user it acts for, goal hijacking, memory poisoning in agents that persist state between sessions, SSRF through fetch and browse tools. Every action the model can trigger is tested as an API call: does the endpoint behind it check authorisation, or does it trust the model? (OWASP Top 10 for Agentic Applications, ASI01–ASI10)
RAG & data exposure
Poisoning of ingested content, retrieval that crosses tenant or role boundaries because the vector store does not know your authorization model, and leakage of other users' context, source documents, credentials and personal data through the model's answers or its logs (LLM02, LLM04, LLM08).
Model output handling
The model's output as an attack vector on everything that consumes it: markdown and HTML rendering (XSS), model-generated SQL or code executed downstream (injection, RCE), automated actions in ticketing, email or CI (LLM05).
The application, infrastructure and supply chain beneath the AI
The APIs, authentication and infrastructure your AI feature sits on; the third-party MCP servers, plugins, model files and adapters your deployment trusts; token, cost and rate limits per user and per tool (LLM03, LLM10). An LLM finding is usually just an entry point — the real impact tends to surface in the layer beneath it.
How we test
Scope follows the OWASP Top 10 for LLM Applications (2026) and, where the system has tools or memory, the OWASP Top 10 for Agentic Applications (ASI) and the OWASP MCP Top 10; the web application and APIs around the model are covered by our standard methodology (OWASP OTG / ASVS). We work grey-box by default: an architecture walkthrough first — which model, which tools, what the model can read and write, which identity it runs under — then manual adversarial testing of the deployed system in a UAT or production-like environment. Automated prompt fuzzing is part of the toolkit; it does not find indirect injection through your documents or a missing authorisation check behind a tool call. Findings are confirmed by exploitation and scored with CVSSv3.
What you get
A report with findings ranked by severity (CVSSv3), reproduction steps and remediation guidance at the prompt, pipeline, tool and infrastructure level. Once your team has deployed the changes, a retest of the findings is included.
Every test is run by certified senior specialists — no junior hands learning on your systems.
Want to see what our report looks like? We'll send you a sample.
Test results can be used for NIS2, DORA, ISO 27001 and AI Act requirements.
Pricing
Scoped by the number of AI entry points, the tools and data sources exposed to the model, and how autonomously agents act — typically 5–10 tester-days. We confirm scope and price on a short call.
Frequently asked, always answered.
Do you test the model or the application?
The application and its integration: prompts, retrieval, tools, output handling and the systems beneath them. Attacks on model weights (extraction, membership inference) are in scope on request; most real-world risk is in how the model is wired into the product.
Which stacks?
OpenAI / Anthropic / Azure APIs, self-hosted models (vLLM, Ollama), LangChain / LlamaIndex-style pipelines, agent frameworks and MCP-based tool integrations, and custom agents.
We already run an automated AI red-teaming tool. Why a penetration test?
Automated tools score the model's behaviour: how often it can be made to violate its instructions. They do not know which tool the model can call, what the endpoint behind it checks, or which documents your users can retrieve. The findings with real impact live there — in the integration, not in the refusal rate.
Let's talk it through.
Tell us what the model can see and do — which tools, which data, which users — and we will propose a scope.
Book a free consultation ›