Security testing for applications with AI features.

A chatbot is a new door into the same database. We test the AI feature and the application around it together: prompt injection, data leaking between tenants, what the agent is allowed to do, and the access-control flaws that AI features quietly reopen.

Why a normal pentest isn't enough

The model is the new user.

Your assistant takes instructions from anyone who can type, and from any document, email or web page it reads. It then calls your APIs with its own permissions. Testing the app without the AI misses the new paths; testing the model without the app misses where the damage lands. We do both in one engagement.

Prompt injection

Direct and indirect: instructions hidden in uploaded files, support tickets, web pages and other users' content.

Data leakage

RAG and search that answer from documents the asking user shouldn't see, including across tenants.

Agent permissions

What the assistant's tools, API keys and MCP connections can do when it is talked into misusing them.

Output handling

Model output rendered as HTML or markdown, executed as code or passed to another system unchecked.

The app around it

Authentication, sessions and authorisation on the endpoints the AI feature introduced, role by role.

Cost and abuse

Rate limits, token budgets and unauthenticated routes that turn your model bill into someone else's tool.

From our work

What AI features have hidden before.

Across the AI-enabled platforms we have tested, from customer-facing assistants to enterprise AI suites, the findings included critical and high-severity issues in access control, session handling and cloud storage alongside the AI functions themselves. In most cases the critical and high items were fixed and confirmed closed at retest. The anonymised profiles show each engagement's scope and outcome.

How it runs

Scope to verified fixes.

  1. Scope call

    What the feature does, what it can read, what it can call, and who uses it. A fixed quote within one business day.

  2. Map the AI surface

    Prompts, retrieval sources, tools and connectors, and the application endpoints behind them.

  3. Test

    Manual testing of the AI paths and the application, with test accounts for each role and tenant.

  4. Report and debrief

    Findings ranked by risk, each with a reproduction and a fix that works for a model, not just a form field.

  5. Retest

    We verify the fixes, including that the same injection no longer works, and update the report.

Questions

Before you book.

We use a hosted model (OpenAI, Anthropic, Azure, Bedrock). What is there to test?

Everything you built around it: the prompts, what the model can retrieve, the tools it can call, how its output is used, and the endpoints that serve it. The model provider secures the model; the application is yours.

How is this different from your AI & LLM security service?

That service focuses on the AI feature itself. This engagement pairs it with a penetration test of the application and APIs around the feature, for teams whose customers or auditors want one report covering both.

Can prompt injection really be fixed?

Not eliminated, but contained. The fixes that matter are architectural: least-privilege tools, retrieval that respects the user's permissions, output that is treated as untrusted, and human confirmation for consequential actions. We test for the flaw and recommend the containment.

Will you need our prompts and source code?

Prompts and an architecture walkthrough help a lot and shorten the test. Source code is optional; we test the running application.

Get secured.

Tell us what you're shipping. You'll get a scoped, fixed quote within one business day.