Overview
US enterprises are adding AI assistants to customer portals and internal tools faster than security reviews can follow, and vendor questionnaires now ask how those features were tested. We test the application around the model: what it can read, which tools it can call, and whether a crafted input makes it reveal data or act for the wrong user. Findings reference OWASP's list of top LLM application risks.
Large language models turn text into instructions, which erases the old boundary between data and code. A model cannot reliably tell your trusted prompt from a hostile one hidden in a document, a web page or a user message, so prompt injection is the central risk we test. We assess both direct injection, where a user manipulates the model, and indirect injection, where content the model retrieves carries an attacker's instructions into the conversation.
From there we follow the consequences through your architecture. Where a model draws on retrieval-augmented generation, we test whether it can be steered into surfacing documents or records the current user should never see. Where it can call tools, browse, run code or write to systems, we assess excessive agency: how much damage a manipulated model can do through the permissions you have granted it. We also check insecure output handling, where model responses flow unescaped into a browser, a shell or a downstream query.
Our work is strictly defensive. We identify weaknesses and show their impact with the minimum necessary evidence, clearly labeled as illustrative, and we never publish jailbreak recipes or attack payloads for reuse. Findings are mapped to the OWASP Top 10 for LLM Applications and translated into controls your team can apply: input and output boundaries, least-privilege tool design, retrieval scoping, and guardrails that fail safe.
How US engagements run
- Delivered remotely from India, 9.5 hours ahead of US Eastern in US daylight time and 10.5 hours in winter; calls and testing windows are set around your time zone at scoping
- Fixed-price proposals in US dollars, with scope, dates and the free retest written in before any work begins
- Written authorization signed by someone with authority over every target, because the federal Computer Fraud and Abuse Act and state laws make permission the dividing line
- Reports that name the requirement a test supports, such as PCI DSS 11.4, the FTC Safeguards Rule or SOC 2, without claiming a QSA, ASV or C3PAO role we don't hold
What's included
Our approach
- Architecture reviewWe map prompts, data sources, tools and trust boundaries in your AI feature.
- Threat modelingWe identify where untrusted text can reach the model and what it can trigger.
- Manual testingTesters probe injection, leakage, agency and output handling against the live feature.
- Impact assessmentConfirmed weaknesses are shown with minimal, clearly labeled illustrative evidence.
- Report & debriefFindings map to the LLM Top 10 with defensive controls your team can apply.
What you receive
- Findings mapped to the OWASP Top 10 for LLM Applications
- Illustrative evidence of impact, no reusable payloads
- Assessment of tool and agent permission design
- Defensive control recommendations that fail safe
- Free retest of fixed issues and an attestation letter
Standards & frameworks
- OWASP Top 10 for LLM Applications
- OWASP WSTG
- OWASP API Security Top 10
- NIST AI RMF
- MITRE ATLAS
- PTES
- CVSS v4.0
- SOC 2
Frequently asked questions
Can prompt injection ever be fully fixed?
Not by filtering alone. Because a model reads all text as potential instruction, the durable defense is architectural: limit what the model can do, scope what it can retrieve, and treat its output as untrusted. We test those boundaries and recommend controls that hold even when a prompt is manipulated.
Do you test models we did not build ourselves?
Yes. Most organizations use a hosted or open model and build features around it, so we focus on your application: the prompts, retrieval, tools and integrations you control. We assess how your design uses the model rather than the provider's internal training.
Is this testing safe to run against our AI feature?
Yes. The work is defensive and non-destructive. We agree boundaries first, avoid actions that would corrupt data or spam real users, and capture only the minimum evidence needed to prove a finding. We never release jailbreak techniques for reuse.
Will a SOC 2 auditor accept your application pentest report?
Penetration testing isn't written into the SOC 2 criteria, yet it is common for auditors and enterprise buyers to look for a recent test. Our report records scope, dates, method and rated findings, and the retest letter shows what was fixed. Your auditor still decides which evidence they accept.
Can testing fit around our US release schedule?
Yes. Testing windows, call times and code-freeze periods are agreed around your time zone at scoping. We deliver from India, which is 9.5 hours ahead of US Eastern during US daylight time and 10.5 hours in winter, and any critical issue is passed to your nominated contact the day it is verified.