Scoping and definition of objectives
Together we determine systems, test access and exclusions. Architecture and data flows form the basis of test planning.
Your situation
AI pentest: testing LLM-based applications
You use artificial intelligence in a web application, mobile app or internal platform? Or you develop your own products with large language model components and want to have their security tested specifically?
Free of charge and without obligation.
- BSI-certified for IS penetration testing
- Methodology based on the OWASP AI Testing Guide
- OWASP Top 10 for LLM Applications
Your situation
Is your existing pentest still sufficient for the AI function?
AI functions are increasingly being integrated into existing applications. Chatbots answer customer questions, internal assistants summarise documents, other systems search knowledge bases or control connected tools. This creates new transitions between instructions, data and actions.
A conventional penetration test still examines the application’s authentication, authorisation and interfaces. AI functions bring additional attack possibilities. You may therefore be asking yourself questions such as:
- Can our chatbot disclose confidential information?
- Can system instructions be bypassed through prompt injection?
- Can manipulated documents influence the behaviour of our AI?
- Does the AI access data or functions it is not authorised for?
- Can attackers reach connected systems via the AI?
- Is our existing web application pentest still sufficient for the AI integration?
An isolated scan of the language model does not fully answer these questions. Many attack paths only arise from the interaction of model, application, data and permissions. An AI pentest therefore specifically examines whether AI functions and their integration can be attacked or misused. If your focus is rather on governing the use of AI in your organisation, an AI management system according to ISO/IEC 42001 helps.
Test areas
What we test in an AI pentest
Which areas are relevant depends on your AI integration. At secuvera, the security analysis covers the entire AI-based application.
Typical test areas
- Prompt injection and controllability: whether manipulated inputs bypass system instructions or influence the behaviour of the AI
- Protection of sensitive information: whether the application unintentionally discloses confidential data, internal content or system instructions
- Roles and permissions: whether the AI can access unauthorised data, functions or tools
- Outputs and downstream processing: whether unvalidated model outputs endanger downstream processes or systems
- Interfaces and third-party systems: whether connected application programming interfaces or data sources can be misused for attacks
- Application and infrastructure: how AI-specific attacks interact with conventional vulnerabilities
When a test is particularly useful
- Before a new AI function goes into production
- During the development of security-critical functions
- After changes to the model, system prompts or data sources
- When the integration accesses confidential or personal information
- When the AI can control tools or third-party systems
- As a regular test of a business-critical application
- As a retest after security findings have been fixed
- When regulatory requirements call for technical security evidence
Useful additions
- Web application or API pentest, if the AI is accessible via web interfaces or application programming interfaces
- Mobile app testing, if the function is integrated into Android or iOS apps
- Cloud security assessment, if models, data or interfaces are operated in cloud services
- C5 consulting, if a cloud service needs to address the requirements of the BSI C5
- ISO/IEC 42001 consulting, if, in addition to technical testing, you want to establish governance, risk management and processes for AI
Services & results
How an AI pentest works at secuvera
You find out whether your chatbots, assistants and other LLM-based functions withstand attacks such as prompt injection, leakage of confidential information or unauthorised access to connected data and tools. You define the systems and scenarios with us; you receive a test report with assessed findings and recommendations from automated and manual tests.
Our penetration testers examine implementation, data flows, interfaces and connected systems. This allows them to identify cross-cutting attack chains as well. The services are not bundled automatically: architecture and scope determine which tests make sense from a technical point of view.
Preparing the test
We identify the relevant attack surfaces and prepare suitable test scenarios.
Carrying out the tests
Automated tools provide reproducible baseline coverage. Manual tests examine context-specific and multi-stage attack scenarios.
Assessing the findings
We review the results manually and assess possible impacts in the context of the application.
Report and results meeting
You receive a test report with traceable findings and recommendations. We explain critical points in the final meeting.
Your result
A test report that presents vulnerabilities, possible impacts and recommended measures in a traceable way. This allows development and security to prioritise findings, target protective measures and have fixed vulnerabilities retested.
Optional retest
On request, we check whether agreed vulnerabilities have been fixed effectively.
Our expertise
AI-specific findings can only be reliably assessed in the specific application context. Automated tools such as garak provide only initial, reproducible coverage. The decisive assessment is made manually by our penetration testers.
Getting started
Defining the AI integration and scope together
Architecture and data flows
For test planning, we need an overview of the model, system prompts, data sources, connected tools and permissions.
Test access and exclusions
Together we define which systems, environments and roles are tested and what remains excluded.
EU AI Act: a reason, but no general testing obligation
The EU AI Act can be an additional reason. Article 15 sets requirements for accuracy, robustness and cybersecurity for high-risk AI systems. An AI pentest can support the technical assessment of cybersecurity by revealing vulnerabilities and attack possibilities. However, the AI Act does not generally prescribe such a test, and the pentest replaces neither legal advice nor a complete conformity assessment.
The AI pentest is a point-in-time examination of the agreed scope. It cannot guarantee lasting or complete security.
Questions about the AI pentest
Is our web application pentest sufficient for the AI integration?
A conventional pentest examines the application’s authentication, authorisation and interfaces. AI functions bring additional attack paths, such as prompt injection or manipulated documents. The AI pentest complements the application test; it does not replace it.
Is an automated scan of the language model enough?
No. Many attack paths only arise from the interaction of model, application, data and permissions. Tools such as garak provide reproducible baseline coverage; the assessment is carried out manually in the context of the application.
When is the right time for an AI pentest?
That depends on the development stage, protection requirements and changes to the system. A test makes sense before a new AI function goes into production, after changes to the model, system prompts or data sources, and when the AI accesses confidential data, tools or third-party systems.
Does the EU AI Act require an AI pentest?
Not as a general rule. Article 15 requires accuracy, robustness and cybersecurity for high-risk AI systems; an AI pentest can support the technical assessment. Which obligations apply depends on the system, the role of the company and the context of use. The legal assessment should be carried out separately from the technical test.
Which tests complement an AI pentest?
An AI function is usually part of a larger application. Depending on the architecture, a web application or API pentest, mobile app testing, a cloud security assessment, C5 consulting or ISO/IEC 42001 consulting may be added. Architecture and scope determine which combination makes sense from a technical point of view.