Teams launching an LLM feature
You are about to put a chatbot, a copilot or AI search in front of customers. We red-team it before launch, so the first jailbreak is ours and not a screenshot on social media.
Your AI Takes Orders.
Make Sure They Are Yours.
Red teaming and hardening for LLM applications, AI agents and the infrastructure behind them — by engineers who also build and run AI systems in production.
Trusted across Europe
Industries we serve.
Engineering teams in regulated, mission-critical industries — every engagement audited, documented, and production-grade.
Banking & Payments
FinTech
PCI-DSS compliant payments and core banking infrastructure — sub-100ms p99 latency, end-to-end audit trail, and tokenization at the edge.
PCI-DSS · ISO 27001
Patient Data
Healthcare
HIPAA-aware patient data pipelines
HIPAA · SOC2
5G & Networks
Telecom
5G core network observability at scale
NFV · ETSI MANO
Retail & Marketplaces
E-Commerce
99.99% uptime during peak traffic events
PCI-DSS · GDPR
Sovereign & Public
Government
Sovereign cloud with full audit trails
eIDAS · FIPS 140-2
Fleet & IoT
Logistics
Real-time fleet tracking & IoT ingestion
MQTT · OPC-UA
10OWASP LLM Top 10 risk categories covered
15+Years building and securing production systems, since 2011
24/7Monitoring and incident response
ATLASFindings mapped to MITRE ATLAS
What we deliver
AI security, end to end
From the prompt to the GPU: the application, the agent, the model, the data and the platform it all runs on.
We test the application around the model the way an attacker would: direct prompt injection, indirect injection hidden in documents, web pages and tool responses, jailbreaks, system prompt leakage, model output that reaches HTML, SQL or a shell unchecked, and data exfiltration through the model — including markdown images and links that send data to an attacker's server. The OWASP Top 10 for LLM Applications is the baseline, not the ceiling.
OWASP Top 10 for LLM Applications · direct and indirect injectionAn agent is only as safe as what it is allowed to do. We define its scope, apply least privilege to every tool and connector — MCP servers, function calling, API tokens — require human approval for sensitive actions, sandbox code execution, and treat the content an agent reads (emails, tickets, web pages) as untrusted, so an instruction hidden in it cannot trigger a sensitive action without approval — then we test that it holds.
Least-privilege tools · MCP · human approvalAdversarial testing of models and AI applications: guardrail bypass, training data extraction, tool abuse, prohibited content and confidently wrong answers where users will act on them. It works like a pentest with its own techniques — and because model output is non-deterministic, every attack is repeated and reported with how often it succeeds.
Mapped to MITRE ATLAS · reproducible transcriptsModels and datasets are code you did not write. We check their provenance and integrity: weights pulled from public hubs, pickle files that can execute code when loaded (we move you to safetensors where possible), poisoned datasets, vulnerable ML dependencies, artifact signing, and who can push to or pull from your model registry.
Provenance · safetensors · signed artifactsSensitive data should never reach training, fine-tuning or retrieval by accident. We review what flows into each stage, enforce per-document access control in RAG so the assistant only retrieves what the user is allowed to see, lock down vector stores and embeddings, and keep personal data out of prompt logs.
Per-document RAG access · vector stores · GDPRCloud and Kubernetes security applied to AI workloads: GPU clusters, inference endpoints, exposed notebooks, MLOps pipelines and the secrets they carry — model provider API keys included. The same platform hardening we apply to production systems, adapted to how ML teams actually work.
Kubernetes · inference endpoints · secrets managementControls that keep working after launch: input and output filters, abuse detection, rate limits and spend caps against denial of wallet, logging of every model interaction and tool call, and an AI incident response playbook so your team knows what to do when a jailbreak goes public.
Input/output filters · rate limits · AI incident responseFree assessment
Get a free AI Security assessment
Our engineers review your current setup and deliver a prioritized roadmap — no strings attached.
Who we help
Teams putting AI in production
The four situations where an AI security review pays back fastest.
Companies deploying AI agents
Your agents read email, tickets or web pages and can act in your CRM, your code or your cloud. We scope what they may do, cut their permissions to the minimum and test whether hostile content can take control.
Organizations with internal copilots
You built a RAG assistant over contracts, HR files or the company wiki. We check that it only retrieves what each user is allowed to see and that nothing sensitive leaks through prompts or logs.
ML teams training or hosting models
You fine-tune or self-host open-weight models on your own GPUs. We secure the supply chain, the pipelines, the notebooks and the inference endpoints around them.
AI red teaming scope
We attack the whole AI system
The model is one component. We test it together with the system prompt, the retrieval layer, the tools it can call and what your application does with its output — that is where real incidents happen. Every finding comes with transcripts, a success rate and a fix.
- Direct and indirect prompt injection
- Jailbreaks and guardrail bypass
- System prompt leakage
- Data exfiltration through the model and its tools
- Training and RAG data extraction
- Excessive agency and tool abuse
- Improper output handling (XSS, SQL and command injection via model output)
- Model supply chain review
- Denial of wallet and resource abuse
Outcomes & method
Security for systems that take instructions
Classic application security assumes code does what it was written to do. An LLM does what its input persuades it to do — so the controls have to assume that, sooner or later, an injection gets through. We design for that outcome and test that the design holds.
Business outcomes
- 01
Known exposure before launch
You see how your AI system fails under attack before customers or attackers do, with every finding reproducible.
- 02
Damage limited by design
Least privilege, approval gates and egress controls limit what a successful injection can reach.
- 03
Evidence for audits and customers
Findings mapped to OWASP and MITRE ATLAS support security questionnaires, ISO/IEC 42001 and the EU AI Act requirements on robustness and cybersecurity for high-risk systems.
How we implement
- 01
Scope & threat model
We map the models, prompts, data sources, tools and users, and build a threat model with MITRE ATLAS.
- 02
Attack
Manual red teaming backed by automated probing, against the application, the agent and the infrastructure underneath.
- 03
Report
Findings with transcripts, success rates and severity, mapped to the OWASP Top 10 for LLM Applications and MITRE ATLAS.
- 04
Harden
We fix with your team: permissions, guardrails, data access rules, pipeline and infrastructure controls.
- 05
Retest & monitor
We rerun the attacks against the fixes and set up logging and alerting for what happens in production.
Engagement model
How we work
From first call to production — a proven 4-step engagement model that keeps the conversation transparent and the velocity honest.
- 01
Discovery
We audit your current stack, identify gaps, and align on business goals.
- 02
Assessment
A detailed roadmap with priorities, effort estimates, and quick wins.
- 03
Delivery
Our engineers embed with your team and execute sprint by sprint.
- 04
Support
Ongoing monitoring, optimization, and knowledge transfer to your team.
Related disciplines
Related services
Adjacent practices that pair well with this one — most engagements blend two or three.
Common questions
Frequently asked questions
Practical answers about scope, timelines, and how engagements with our AI Security team usually look.
A classic pentest looks for flaws in code, configuration and authentication — a vulnerability is either there or it is not. In an AI system, natural language is the attack surface: the same prompt can succeed once in ten attempts, the payload can arrive inside a document the model reads, and the fix is rarely a single patch. We still test the classic layer — the API, authentication, the cloud underneath — because an AI application is also a web application. On top of that we test the model's behavior, its tools and its data, using the techniques catalogued in MITRE ATLAS and the OWASP Top 10 for LLM Applications.
No, and anyone who promises that is overselling. Current models receive instructions and data through the same channel, so no filter can reliably tell them apart. What works is defense in depth that assumes an injection will eventually succeed: treat model output as untrusted, give tools the least privilege possible, require human approval for consequential actions, keep trusted and untrusted content separate, close exfiltration paths such as outbound requests and rendered images, and monitor for abuse. Filters and classifiers lower the success rate; architecture limits the damage. We test both.
Yes. Most AI applications are built that way, and the risk usually sits in your application rather than in the provider's model: the system prompt, the retrieval layer, the tools the model can call and what your code does with its output. We test your application and integration — not the provider's models or infrastructure — and stay within the provider's usage policies. Findings that depend on model behavior should be re-checked whenever you change the model or its version.
We start from what the agent should be allowed to do, not from what it can do. Each tool and MCP server gets its own narrowly scoped credentials; write and delete actions, payments and outbound messages require human approval; code execution runs in a sandbox without access to secrets or the internal network. We review MCP servers like any third-party dependency — tool descriptions can carry hidden instructions, and a server can change its tool definitions after you approved it — so we pin versions and allowlist what can be installed. Then we test whether content the agent reads can take over its actions.
An executive summary with the overall risk, the scope and method, and every finding with its severity, the exact prompts or payloads used, the transcripts, and how often the attack succeeded across repeated attempts — model output is non-deterministic, so a single screenshot is not evidence. Each finding is mapped to the OWASP Top 10 for LLM Applications and MITRE ATLAS and comes with a concrete fix: a permission change, a guardrail, a data access rule or an architecture change.
Yes. Once you have remediated, we rerun the same attacks — same payloads, repeated the same number of times — and report the new success rates next to the original ones. Because a model update, a new tool or a change to the system prompt can reopen a closed issue, we can also turn the attack set into a regression suite that runs in your CI/CD pipeline before each release.
Talk to engineering
Let's talk about your AI Security strategy
Whether you're starting from scratch or scaling what you have, our engineers are ready to help.