Cybersecurity
LLM security assessments
We test the application around the model: how it handles untrusted input, what data it can reach, what it does with model output, and what happens when an attacker steers it.
The problem this service solves
A language model treats everything in its context as potential instructions. A customer message, a web page the assistant summarizes, a PDF a user uploads or a record pulled from a database can all carry text that redirects the model. Because of that, the model cannot be trusted to enforce your security rules.
The question for an LLM feature is therefore not "can the model be tricked?" (it can) but "what can a tricked model do?" That depends on identity, permissions, output handling and monitoring, and those are testable.
What is in scope
-
Prompt injection (LLM01)
Direct attempts through user input, and indirect attempts through documents, web content, email and tool results.
-
Sensitive information disclosure (LLM02)
Whether the model can reveal personal data, secrets, other users’ data or internal documents.
-
Supply chain (LLM03)
Model sources, plug-ins, libraries, datasets and third-party services used in the application.
-
Improper output handling (LLM05)
Model output rendered as HTML, run as code or passed into queries and commands without validation.
-
Excessive agency (LLM06)
Tools and permissions the application grants the model, and whether sensitive actions need approval.
-
System prompt leakage (LLM07)
Whether secrets or security logic live in prompts, and what an attacker learns from the prompt.
-
Unbounded consumption (LLM10)
Cost, rate and resource abuse, including expensive queries and denial of wallet.
-
Logging and monitoring
Whether abusive prompts and tool calls are recorded and reviewable, without storing more personal data than necessary.
How the work runs
Map
Understand the system.
-
1
Architecture and data flow review
Identify inputs, retrieval sources, tools, identities and trust boundaries.
-
2
Threat model
Rank abuse scenarios by impact, using the OWASP list as a checklist, not the whole plan.
Test
Attack the system.
-
3
Adversarial prompting
Craft direct and indirect injections, including multi-step and multilingual variants.
-
4
Boundary testing
Attempt to read other users’ data, trigger actions or exfiltrate data through output channels.
-
5
Application testing
Test the surrounding web and API layers like any other application.
Report
Prioritize controls.
-
6
Findings and fixes
Controls that work independently of model behavior: authorization, output validation, approvals, isolation.
-
7
Retest
Verify changes with the same attacks.
What you receive
- Executive summary
- Threat model of the AI feature
- Findings mapped to OWASP LLM Top 10 (2025)
- Reproduction transcripts
- Control recommendations at the architecture level
- Retest results
Tooling and technique
Open-source tools support the work. We do not claim a proprietary AI security product.
Standards we map to
Mapping findings to a framework is not the same as certification against it.
Before we start
What we need from you
- Access to the application in a test environment
- Architecture diagram and a list of tools and data sources
- Test accounts at different permission levels
- Policies on what the assistant must not do
What this service is not
- A model evaluation or benchmark
- Content moderation or brand-safety testing as the main goal
- An assurance that prompt injection is impossible
What changes afterwards
- Sensitive actions require authorization that the model cannot override
- Model output is treated as untrusted input
- Abuse is visible in logs
Questions people ask
Can prompt injection be fully prevented?
Not today. Current models cannot reliably separate instructions from data. Defenses limit what an injected instruction can achieve: least privilege, approval steps, output validation and isolation of untrusted content.
Do you test the model provider’s model?
No. We test your application and the choices you made around the model. Provider-level safety is outside scope.
Is this relevant for an internal copilot?
Yes. Internal tools often have broader data access than customer-facing ones, and attackers can plant instructions in shared documents or tickets.
Related
-
RAG security
Review retrieval-augmented generation: document-level authorization, poisoning, embedding exposure and leakage through answers.
-
AI agent security
Review agents that plan and call tools: identity, tool permissions, approvals, memory, isolation and audit.
-
API penetration testing
Testing REST, GraphQL and internal APIs for broken authorization, tenant isolation failures, token weaknesses and business-logic abuse.
Need to understand your security exposure?
Speak with a security expert
Talk through your environment and goals. We reply to scope the work before anything is tested.
Speak with a security expertPlan an assessment
Answer a few questions and get a structured preliminary scope you can send us.
Use the plannerUnder attack right now?
Call the US office and tell us what you are seeing. Do not wait for a form reply.
Incident response