AI / LLM Penetration Testing
AI & LLM penetration testing for applications and agents
Manual testing of AI admin access, tenant isolation, RAG data and agent tools. Get reproducible findings, prioritised fixes and a retest from senior application testers.
Agree the features, accounts and environments in scope before testing. NDA available before sensitive details.
Case study: an AI admin authorisation gap →
Follow the AI trust boundaries.
Map the caller, the administration surface and the systems the AI feature can reach.
Start with the control plane, not the chatbot
Most AI security testing is a conversation with a model. But an AI feature bolted into a business application is a small distributed system: something stores the prompt configuration, something creates and trains models, something triggers the ingestion jobs, and something holds the credentials the pipeline uses to reach object storage and your business data. All of it is configuration, all of it is exposed over HTTP, and all of it is a far shorter path to impact than persuading a model to misbehave. We test that surface first. (It’s the argument behind our write-up on the AI admin plane.)
We work at the request level as an ordinary tenant user, not through the admin console — because we have found AI administration services that accepted privileged writes from a plain business user while the interface hid those screens in the browser alone. Prompt injection, direct and indirect, is tested as a route into that system rather than as the headline.
What we test
- AI admin plane: prompts, models, ingestion triggers
- Pipeline storage and business-system credentials
- Tenant isolation of conversations, documents and artefacts
- Agent and tool authority boundaries
- Prompt injection, direct and indirect
- Data path, retention and AI endpoint hardening
Why it matters
Why prompt injection is not where the risk starts
An AI feature inside a business application is not simply a model; it is a small distributed system with its own administration surface. Something stores the prompt configuration the model executes. Something creates models, starts training runs and deletes them. Something triggers the jobs that pull your business data into the corpus. And something holds the credentials the pipeline uses to reach object storage and the systems around it. That surface usually arrives as a vendor enablement step rather than as a design review, so nobody in your organisation ever chose its permission model, and by the time anyone asks who can write the prompt store, the answer has been true in production for months.
The asymmetry is practical rather than philosophical. Prompt injection buys an attacker influence over one session's output, within whatever the model was already permitted to do. Write access to the administration plane buys the pipeline's credentials, the instructions every user receives, and the choice of what the feature reads and where its data is written. We have tested AI administration services that accepted privileged writes from an ordinary non-administrator tenant user, because the administrator gate was hidden in the browser and the services themselves checked only a coarse service-level scope. A neighbouring identity service on the same platform refused that same user outright, which proved the gate existed and had simply never been applied to the AI surface. Found in time, that is usually one enforcement decision rather than a long list of endpoint bugs.
How it works
Scope and accounts
We agree the AI features in scope and the least-privileged test accounts.
Map the surface
Endpoint inventory from the client bundle, the orchestration layer and the assistant itself.
Authorisation first
Every mutating operation replayed with an ordinary user’s token, then the agent boundary and injection.
Report and retest
Prioritised fixes — usually one enforcement decision — then verified.
Why PXLSec
What sets our AI testing apart
The administration plane tested first
We enumerate the prompt configuration, model lifecycle, ingestion triggers and pipeline credential records the AI feature owns, then replay every mutating operation with the most ordinary business token your tenant will issue us, and record what the server actually enforces rather than what the interface implies.
Authorisation and tenant isolation
We create content as two users and walk the identifier space in both directions across conversations, documents, embeddings and generated artefacts, testing retrieval, metadata, export and delete separately, because an ownership check is often present on one verb and missing on the next.
The agent and tool boundary
Where the feature can act rather than only answer, we establish exactly what it is authorised to call on a user's behalf, whether that authority can be steered by content it reads, and whether the tool layer re-checks the caller's entitlement or simply trusts the orchestration above it.
Injection judged by what it reaches
We test direct and indirect prompt injection, then rank it by the system it touches: a tool call, a credential, another tenant's data. A prompt store an ordinary user can write is a real finding even when nothing consumes it yet, because the authorisation defect is live and only the consumer is absent.
What you receive
Clear deliverables, agreed in the proposal, with no surprises at the end of the engagement.
- Executive summaryBusiness-level risk, written for leadership and boards.
- Technical reportEvery finding with severity, evidence and reproduction.
- Prioritised fixesDeveloper-ready remediation, ranked by real risk.
- Retest letterWe verify your fixes and confirm closure in writing.
When you need this
When an AI security test pays off
These are the moments when testing answers a question the design documents cannot.
Before an AI feature reaches customers
A generative feature is about to go live and you want to know who can reach its prompt configuration, its credentials and its model lifecycle before real tenants and real adversaries arrive.
AI switched on by the platform vendor
The capability arrived as a feature flag or a provisioning step, the default role mapping came with it, and nobody in your organisation reviewed what it granted to the business users who already had logins.
Agents that act, not just answer
Your assistant can call internal services, read records or write data on a user's behalf, and you need that authority boundary tested rather than inferred from how the orchestration was meant to work.
Governance and customer assurance
Your board, your insurers or an enterprise prospect are asking specific questions about the AI features you ship, and an internal AI governance programme needs independent technical testing evidence underneath it.
Methodology & standards
Methodologies and references we draw on
- OWASP Top 10 for LLM Applications
- OWASP Agentic Security Initiative
- MITRE ATLAS
- NIST AI Risk Management Framework
- OWASP API Security Top 10
- OWASP WSTG
- ISO/IEC 42001 and EU AI Act context
FAQ
Questions we're often asked
Is this just prompt-injection testing?
No, and that is rather the point. Prompt injection is one component of the engagement, not the headline. We start with the AI administration plane: who can write the prompt configuration, reach the pipeline's storage and business-system credentials, trigger ingestion and operate the model lifecycle, and whether the administrator gate is enforced by the server or merely hidden in the interface. Injection is then tested for what it reaches, rather than as an end in itself.
Our AI feature came with the platform rather than being built in house. Is that in scope?
Yes, and it is where we tend to find the most. Vendor-enabled AI arrives with a permission model your organisation never chose, frequently authorised at the granularity of a whole service rather than per operation, so a role handed to ordinary staff can cover administration as well as everyday use. We test it as your tenant actually sees it, and write the findings in a form you can take to the vendor, including the response returned for each operation.
What access and test accounts do you need?
Ideally two ordinary non-administrator accounts in the same tenant and the same role, so we can test isolation between users, plus one administrative account for comparison and a second tenant if you are willing to include one. Least privilege is the test: most of the serious findings come from calling administrative operations with an account that asserts nothing. We also ask for whatever endpoint, orchestration or tool documentation already exists.
Will testing disrupt the AI feature or change our data?
We agree scope, rules of engagement and timing before anything is sent. Operations that consume resources or alter state, such as triggering ingestion, starting a training run or writing a live prompt configuration, are exercised only with your explicit permission, and we prefer to demonstrate the authorisation gap against a record we created ourselves. Where a non-production environment reflects the same authorisation model, we are glad to work there instead.
Does this certify us against the EU AI Act, ISO/IEC 42001 or the NIST AI Risk Management Framework?
No. We are an offensive-security testing firm, not an auditor, an assessor or a certification body, and we do not issue certificates or attestations against any framework. We reference those documents for what they genuinely are, and our technical findings and evidence can be used by whoever runs your governance, audit or conformity work. Where a framework calls for independent technical testing, this is that testing.
What do we receive at the end?
An executive summary written for leadership, a technical report with every finding, its severity, the evidence and the exact requests needed to reproduce it, and prioritised remediation. For administration-plane findings that usually means one scoping and enforcement decision rather than a list of separate endpoint fixes. Once your team has remediated, we verify the fixes and confirm closure in writing.
Related services
Discuss your testing scope.
Tell us what you want to protect. A senior tester will help you agree the scope and next steps. We usually reply within one business day.
Confidential from the first conversation
We can sign your NDA before you share sensitive details. Your enquiry is covered by our privacy policy.
How we protect your information · Privacy policy