AI Security & Red Teaming
We attack your LLM apps, chatbots and agents before someone else does.
Prompt injection, jailbreaks, data leakage, unsafe tool use, RAG poisoning — tested against the OWASP Top 10 for LLM Applications and MITRE ATLAS, only with your written authorisation and an agreed scope.
AI SECURITY, TESTED THE WAY ATTACKERS WORK
Your AI feature is a new attack surface.
A language model follows instructions from any text it reads. Security means deciding what it may do when it does.
A support chatbot that reads customer emails, an agent that can search the CRM and send messages, an assistant that answers from your shared documents: each of them mixes trusted instructions with untrusted content in the same context window. A hidden line in a PDF, a web page or a ticket can tell the model to ignore its rules, reveal its system prompt, return another customer's data or call a tool it should not call. Classic web scanners do not see these problems, because the vulnerability is in how the model, the prompts, the data and the tools are connected.
We test LLM applications, chatbots and agents the way an attacker would, using the OWASP Top 10 for LLM Applications and MITRE ATLAS as the frameworks we map every finding to. This is for teams about to launch an AI feature, SaaS products where several customers share the same assistant, companies giving AI agents access to internal systems, and apps built quickly with AI coding tools that now handle real data (see vibe coding). We work only on systems you own or are authorised to test, under a written scope.
Red teaming assessment
Manual and automated attacks on your chatbot, agent or RAG system: injection, jailbreaks, data extraction, tool abuse. Every finding comes with severity, reproduction steps and a concrete fix.
Guardrails and hardening
We implement the fixes with your team: least-privilege tools, confirmation for sensitive actions, tenant isolation in retrieval, input and output filtering, safe rendering of model output.
Retest and monitoring
We retest every fixed finding, turn the attacks into a regression suite you can run on each release, and set up logging and alerts for abuse, leaks and unusual spend.- Direct prompt injection and jailbreaks
- Indirect injection through documents, emails, web pages and tickets
- System prompt and configuration leakage
- PII exposure and access to other tenants' data
- Excessive agency and unsafe tool calls
- Insecure output handling: XSS, SQL, shell and links from model output
- Supply chain: models, plugins and MCP servers
- RAG and vector store poisoning
- Denial of wallet: runaway token spend and rate limits
- Guardrails, logging and monitoring after the fixes
WHAT YOU RECEIVE
Findings you can act on, not a scary score
Written for the engineers who fix things and for the people who sign off on risk.
- A written scope and rules of engagement, signed before any test starts: systems, accounts, data, time windows and what is off limits.
- A threat model of your AI system: data flows, trust boundaries, tools and the permissions each one has.
- A findings report: each issue with severity, the OWASP LLM and MITRE ATLAS reference, exact reproduction steps, impact and a recommended fix.
- A short executive summary for management, without jargon.
- Implementation of guardrails and fixes, by us or together with your developers.
- A retest of every fixed finding, with an updated report.
- An attack regression suite and monitoring setup, so the same holes do not reopen with the next prompt or model change.
We work with the stacks our clients use: OpenAI and Anthropic Claude APIs, open-weight models like Llama, Mistral and Qwen on vLLM, agent frameworks such as LangGraph, MCP servers, PostgreSQL with pgvector and other vector stores. Testing combines hand-written attacks with open-source tools for automated probing, and the results feed directly into the evaluation pipelines we build in AI testing and evaluation. If the safest fix is to keep data and models in-house, we can run them on our own GPU cloud in Cluj-Napoca (see private AI).
HOW WE WORK
From written scope to verified fix
Authorised, documented and repeatable.
Scope and authorisation
We agree in writing what we test, which environment and accounts we use, and how we report anything critical found along the way.
Threat model
We map prompts, data sources, tools and permissions, and decide which attacks matter most for your system and your users.
Attack
Manual red teaming plus automated probing across the OWASP LLM categories, with every attempt and response logged as evidence.
Report
Findings ranked by severity, with reproduction steps and fixes, walked through in a call with your engineers.
Fix and guardrails
Architecture changes first, then filters and classifiers. We implement or review every change before it ships.
Retest and monitor
We confirm each fix holds, keep the attacks as regression tests and watch production for abuse and unusual cost.FAQ
Common questions
How is this different from a classic penetration test?
A classic pentest looks at networks, servers and web vulnerabilities. An LLM application adds a component that takes instructions from any text it reads, so the attacks are different: prompt injection through documents and emails, model-driven misuse of tools, leaks through generated answers. We cover the AI-specific layer and the application around it (APIs, authorisation, output rendering); for a full infrastructure pentest we can work alongside your existing security provider.
Do you test our production system?
We prefer a staging environment with realistic data and the same configuration as production. Testing production is possible only if you agree to it in writing, with clear limits on rate, accounts and data. We never test anything outside the agreed scope, and we stop and notify you immediately if we find something that puts real data at risk.
Which models and platforms can you test?
Applications built on hosted models such as OpenAI or Anthropic Claude, on open-weight models like Llama, Mistral or Qwen served with vLLM or Ollama, and agents built with frameworks such as LangGraph or with MCP servers. What matters is not the model, but what the system around it can read and do.
Can guardrails stop every prompt injection?
No, and anyone who promises that is overselling. Filters and classifiers reduce the success rate, but the reliable defence is architectural: least privilege for tools, confirmation for sensitive actions, separation between trusted instructions and untrusted content, and authorisation enforced in code, not in the prompt. We design for the case where an injection succeeds and make sure the damage stays small.
Does this help with EU AI Act obligations?
The AI Act asks providers of high-risk systems to address accuracy, robustness and cybersecurity, including attacks such as data poisoning and adversarial inputs. A documented red teaming exercise with findings and retest results is useful evidence for that. For the wider classification and documentation work, see our EU AI Act compliance service.
Shipping an AI feature? Have it attacked first.
Tell us what your system does, which data and tools it can reach, and we will propose a written scope for the assessment.