AI red teaming

AI red teaming for LLM apps and agents

We attack your LLM app, agent or MCP server the way a hostile user or a hostile document would. Inside a scope you authorize, we try to make it leak data or misuse its tools.

What we test

• Prompt injection: instructions typed by a user, and instructions hidden in a web page, document, email or tool result that the model reads.
• Tool abuse: whether the model can be pushed to call a tool it should not, or call an allowed tool with harmful arguments.
• Data exposure: whether one user can get another user's data, or text meant to stay private, through the model.
• Unsafe output: whether model output reaches a browser, a database or a shell without a check.
• MCP servers: what each tool exposes, who may call it and what it returns.

Why the plain checks still matter

Most AI incidents end in an old bug. A tool that fetches a URL can be an SSRF path. A tool that reads a record for the wrong user is an access control bug. We test the tools and data paths around the model with the same care as the model.

What it looks like

We agree the models, tools and data sources in scope, and a test account for each role. We write attacks for your product, not a generic list. Model answers can vary between runs, so we record each attempt and its result. You can replay it.

What to have ready

• A test environment for the AI feature, with realistic data.
• One account for each role.
• A list of the models, tools and data sources the feature can reach.
• The worst outcome you fear, such as a data leak or a wrong action by an agent.
• Written authorization for every system the agent can touch.

How an engagement runs

1. Scoping call. A short call about what you need, who will read the report and your deadline. We send a written scope and a quote.
2. Authorization. Testing starts only after the owner of each system signs written authorization. Do not send passwords or keys.
3. Testing. We test inside the agreed scope, with test-owned accounts and data.
4. Report. You get evidence, reproduction steps and a fix for each finding.
5. Retest. After you ship fixes, we can verify them. The quote states the retest terms.

Safety limits

• We test only with written authorization from the system owner.
• Destructive proofs use only accounts and records we create for the test, marked as test data.
• Tests of uploads, password guessing, email sending and paid third-party APIs have limits, and the report states what they cost.
• Reproduction scripts are read-only where possible.

What you get

A report in HTML, PDF and Markdown. Each finding has the prompt or input, the result, reproduction steps and a fix. The report lists the safeguards that held. The sample report shows the format on a web app. It is written for a fictional app.

• Scope, assets and a four-level severity scale: Critical, High, Medium and Low
• An executive summary with priority actions
• One section per finding: description, impact, verified results, reproduction and fix
• Controls that held, so your fix does not break them
• A remediation plan, plus limitations and open questions

Related research

Each post below has a local fixture with real recorded requests and responses. The code is public in web-security-fixtures on GitHub.

• SSRF: reproduce, bypass and fix a preview endpoint
• Broken access control: vertical privilege escalation
• Authorization testing for APIs

Questions

What do you need from us?

Access to a test environment, one account for each role, and a list of the models, tools and data sources the feature can reach. Do not send keys through the form.

Do you test the model itself?

We test your product: its prompts, tools, data paths and safeguards. The scope names the models it uses.

Do you test agents that call other systems?

Yes, inside the scope. Every system an agent can reach needs written authorization from its owner.

How is this different from a penetration test?

A penetration test targets the app and API. AI red teaming adds prompts, tools and data paths. Many AI products need both.

How much does it cost?

We quote the scope in writing after a short call. We publish no prices.

To see how a quote is built, read pricing. For the full method, read application security assessment.