Find the holes before someone else does.

You find out what is open in the system and the language model you already run, in writing, with remedies and deadlines. For the system that is already running, with or without AI.

HOW IT GOES

  1. Scope and authorisation

    Agreed in writing: what is tested and what is not touched. Without that it is not a test.

  2. Mapping

    What is exposed, what you are actually running, and what a language model in the system can reach.

  3. Testing

    I try to get in, and further once I am in. If there is a language model in the system, prompt injection, jailbreaks and attempts to pull data out through it are run. Everything is logged.

  4. Report, guardrails and retest

    The findings with severity and remedies. Guardrails around the model go in the code, not in the instructions to it. Once you have fixed them, the same test again.

WHAT IS INCLUDED

Sixteen things are included. And every finding is counted and ranked.

EXAMPLE

Websites, systems and infrastructure

Every finding, ranked by how serious it is

EXAMPLE

What is open from the internet

EXAMPLE

Who has access to what

EXAMPLE

Signing in, and how long a session lasts

EXAMPLE

Personal data: what is kept, and for how long

EXAMPLE

Operations, updates, and what the system is built on

EXAMPLE

What to do first

EXAMPLE

The report you can hand on

EXAMPLE

Language models and LLM guardrails

Mapping the attack surface

EXAMPLE

Prompt injection testing

EXAMPLE

System prompt and data leakage

EXAMPLE

Tool and API abuse

EXAMPLE

Guardrails in the code

EXAMPLE

Logging of refused attempts

EXAMPLE

Retest and verification

EXAMPLE

Report and board summary

EXAMPLE

What do you receive after a penetration test?

You receive a written report with findings, severity and practical remedies. Testing examines exposed functionality and access controls within the agreed scope. Relevant tests are repeated after fixes. A penetration test describes what was examined; it does not guarantee a system has no vulnerabilities.

Define the system and scope to be tested

What is tested when the system has a language model?

A review examines what a language model can access, which actions it can take and whether unwanted instructions can bypass its boundaries. Westengen Studio tests prompt injection, jailbreaks and potential data leaks in a controlled environment. Findings are documented, controls are added around the model and the attacks are repeated.

Read the prompt injection and AI security guide

Is a good system prompt enough to secure a chatbot?

A system prompt alone is not an access control. Knowledge base retrieval, tool calls and outgoing data need boundaries enforced by the application. Before a review, list the documents, systems and actions the chatbot can reach. This provides a practical starting point for defining the test scope.

See how a chatbot is built with the limits in the code