Pentesting AI & LLM Applications: OWASP LLM Top 10 in Practice

Classic web pentests catch the IDORs around your LLM, but miss the LLM itself. Prompt injection, tool abuse and unsafe output handling are not findings your scanner will surface.

OWASP's LLM Top 10 is now the de-facto reference. Buyers in regulated industries are starting to ask for it explicitly.

Direct injection (the user types 'ignore previous instructions') is the obvious case. Indirect injection — payloads in a PDF, an email, a webpage or a tool response — is where real impact lives.

We test every untrusted text path that reaches the model and every tool the model can call. The blast radius is whatever the model can do on the user's behalf.

LLM output rendered as HTML is a fast path to stored XSS. Output passed to `eval`, a shell, an SQL builder or a templating engine is RCE waiting to happen.

Treat the model as a partially trusted user. Sanitize, sandbox and constrain everything it returns.

When the model has tools (browse, code, email, database), the security boundary becomes 'what tools can this user persuade the model to call?'. Tool-level authorization, not model-level, is the right control.

We test for tool confusion, parameter smuggling, and chained tool calls that escalate privilege via the agent.

RAG systems leak embeddings, training data and other tenants' content when authorization is missing at the vector-store query. Fine-tuned models memorise PII surprisingly often.

System prompts are not secrets — assume they will be extracted. Real secrets stay in tool implementations.

Define what the model is allowed to do and to know. Test every untrusted path to the model. Test every tool the model can call. Test the surrounding app the classical way.

Repeat after every model change, system-prompt change, or new tool. StartSecure ships LLM-aware test plans as part of API and web engagements.