Human-led AI security testing
Test what your AI application can retrieve, reveal, and do. The PenTesting Company tests prompt injection, data boundaries, tool permissions, and the app and APIs around the model.
Authorized testing only, with written authorization and agreed limits for each asset in scope.
Green markers show test points at trust boundaries. Arrows show request or data paths, not permission to test an adjacent system.
User input
Direct prompts, uploads, sessions
Test: Injection and identity
App / orchestrator
Context assembly and output handling
Test: Tenant and output boundaries
Model
The model provider's API, when in scope and authorized
Test: Disclosure and consumption
Retrieval / vector store
Documents, embeddings, tenant filters
Test: Indirect injection and access
Tools / plugins
Function calls and approval gates
Test: Arguments and permissions
Downstream APIs
Actions, records, rendered responses
Test: Server-side authorization
A retrieved document is data, not authority. A model suggestion is not permission to act.
A refusal message is not an access control. A convincing answer is not proof that a tool ran. We follow the data and action across the boundary that should enforce permission.
An LLM application can combine a user interface, an orchestrator, a model, retrieval-augmented generation (RAG), and tools that act through APIs. A prompt-level issue becomes a security finding when the evidence supports the impact and the agreed objective. We test those connections within the written scope.
AI application testing complements web application security testing. The app still needs authentication, server-side authorization, and tenant isolation even when a model mediates the request. For an assistant embedded in an app, the mobile client can be scoped separately.
These are candidate coverage areas. Your architecture, written authorization, and rules of engagement determine which checks can be performed.
LLM01:2025 Prompt Injection
Vary user prompts and instructions embedded in agreed uploads or retrieved documents. Check whether untrusted content changes the assistant's instructions, exposes protected data, or steers a tool call. A changed answer alone is not evidence of unauthorized access.
LLM02:2025 Sensitive Information Disclosure; LLM07:2025 System Prompt Leakage
Use agreed test records to probe conversation history, context assembly, error messages, and prompt extraction. Distinguish disclosure of non-secret instructions from exposure of credentials, protected records, or security-relevant configuration.
LLM05:2025 Improper Output Handling
Trace model-generated text and structured output into renderers, database queries, command arguments, and downstream APIs where those sinks are in scope. Check validation, escaping, and server-side controls rather than treating model output as trusted input.
LLM06:2025 Excessive Agency
Exercise tool and function calls with agreed low-risk actions. Check argument constraints, least privilege, approval gates, and whether the server rechecks the acting user's permission. An assistant's claim that it completed an action is not proof that an API accepted it.
LLM08:2025 Vector and Embedding Weaknesses; LLM01:2025 Prompt Injection
Compare retrieval results between agreed users and tenants, including document identifiers, metadata filters, caches, and citations. Check authorization at retrieval and record access, and test whether an authorized seeded document can introduce indirect instructions.
LLM02:2025 and LLM08:2025 where disclosure involves model context or retrieval
Test sessions, conversation ownership, object access, and role checks in the surrounding application and agreed APIs. These are also conventional application security risks, not a separate LLM Top 10 category. We compare API behavior with the assistant's behavior.
LLM10:2025 Unbounded Consumption
Within agreed request, token, and cost limits, examine quotas, input sizes, retries, tool loops, and per-user limits. Load or denial-of-service testing is not assumed. Stop conditions and resource budgets belong in the rules of engagement.
LLM03:2025 Supply Chain
Review the agreed inventory, model and package provenance, version pinning, update paths, and integration permissions. This is a review item, not permission to attack dependencies, model hosts, or third-party infrastructure.
References: OWASP Top 10 for LLM Applications (2025) supplies the risk IDs above. MITRE ATLAS informs adversarial scenarios such as direct and indirect LLM prompt injection. These frameworks guide planning; they do not establish complete coverage or a predetermined finding count.
From asset authorization to reproducible evidence. The application boundary and the business impact matter more than a list of jailbreak prompts.
| Phase | What testers do | What you provide or receive |
|---|---|---|
| Scope and authorize | Agree app hosts, models and integrations, roles, tenants, safe actions, data handling, resource limits, and stop conditions. Obtain written authorization from whoever controls each asset. | You provide an architecture outline, test accounts, asset authorization, and a named contact. The statement of work and rules of engagement define coverage. |
| Map trust boundaries | Trace input, system context, retrieval, model responses, tool arguments, and downstream actions. Identify where identity and permissions should be enforced outside the model. | You provide tool schemas, retrieval design, and relevant code or logs when agreed. We use OWASP LLM Top 10 and MITRE ATLAS to plan applicable scenarios. |
| Exercise adversarial scenarios | Test the agreed prompt, retrieval, output, tool, and application boundaries. Vary inputs and compare roles using synthetic records, within the agreed limits. | You keep the scoped environment and accounts available. Coverage focuses on applicable risks, not an assertion that every framework item is tested. |
| Confirm impact manually | A tester reproduces candidate issues and checks retrieval traces, API responses, or action logs where available. Record unsuccessful attempts and conditions that limit repeatability. Stop at the agreed proof of impact. | You provide any decisions the rules of engagement require. Evidence separates a model's statement from a verified disclosure or action. |
| Report and read out | Document confirmed findings with reproduction inputs, relevant model and app configuration, observed impact, severity rationale, and remediation at the failing boundary. | You receive the scoped report and a readout. Evidence can include redacted conversation traces, document IDs, tool arguments, and API results. Retest terms set in the statement of work. |
If we confirm a critical-severity issue during testing, the rules of engagement set how and how quickly your named contact is told, rather than waiting for the report.
Illustrative only, not a client or past engagement
Example Corp runs a support assistant at assistant.example.com with a scoped API at api.example.com (192.0.2.40). It retrieves tenant-specific help documents and offers a tool to draft a support ticket. These domains and the RFC 5737 address are placeholders. The scenario uses synthetic records, not customer data.
Remediation would enforce tenant filters at retrieval and record access, derive action permissions from the authenticated session, constrain tool arguments, and require approval for sensitive actions. Treating retrieved text as untrusted remains useful, but a stronger instruction in the system prompt would not replace those controls.
When a retest is agreed, the tester would repeat the confirmed path with both tenant accounts and check that legitimate access still works. Retest terms set in the statement of work.
Our testers use AI tooling to help generate and vary test inputs, review large volumes of responses and code, and flag leads for a human to verify. This can help surface issues that are easy to miss in manual review.
Every reported finding is manually confirmed by a tester. AI-generated suggestions and candidate issues are leads, not findings on their own. Testers check the evidence, assess impact, and decide what belongs in the report.
Client data is handled per the rules of engagement and the statement of work. We agree permitted tooling and data handling before testing; AI assistance does not expand the authorized scope or remove the agreed resource limits and stop conditions.
Tell us how the application makes decisions and what it is permitted to access. Do not send production secrets through the contact form.
Questions about AI application scope, evidence, authorization, and human verification.
It is an authorized test of an AI application's security boundaries, including prompts, retrieved content, tool calls, and the surrounding app and APIs named in scope. The PenTesting Company uses human-led testing to confirm whether a candidate issue can expose protected data or enable an unauthorized action.
The terms overlap. An application penetration test focuses on exploitable weaknesses in a defined application and practical remediation. AI red teaming can describe a wider goal-based exercise, including model behavior, safety policies, and operational response. We agree security objectives and exclusions in writing; this service does not imply a broad model safety or bias evaluation.
No third-party infrastructure is assumed to be in scope. Testing can include the model provider's API, when in scope and authorized. Permission from an application owner does not by itself authorize testing a provider's systems. The written scope identifies the assets and any additional permissions required.
It depends on the agreed objective and demonstrated impact. A policy-violating response is not automatically an application security vulnerability. We distinguish exposed non-secret instructions from sensitive data disclosure and check whether a changed response crosses a real data or action boundary.
Our testers use AI tooling to assist with test inputs, response and code review, and candidate leads. Every reported finding is manually confirmed by a tester. AI assistance does not replace tester judgment or expand the authorized scope. Client data handling follows the rules of engagement and the statement of work.
Written authorization, scoped hosts, an architecture outline, accounts for the roles and tenants being compared, and synthetic records are a useful starting point. Tool definitions, retrieval configuration, code, and logs can be included when agreed. Data handling, permitted tooling, resource limits, and stop conditions are set before testing.
Coverage depends on the architecture and written scope. Data and Model Poisoning (LLM04:2025) and Misinformation (LLM09:2025) are not assumed to be standalone workstreams in this service. We discuss their relevance during scoping. A penetration test is not a compliance certification. A report records what is confirmed within the agreed scope and window. Retest terms set in the statement of work.
Tell us about your assistant, retrieval pipeline, or tool-using application. We will discuss the boundaries and access to include in a written scope.
