A defined release or decision
Raxis Strike
Discuss a focused testing window for a launch, major integration, or scheduled assessment. Define the application, roles, and connected systems to test around that milestone.
AI & LLM Penetration Testing Services
Your customer. Someone else’s answer.
Your AI should know which customer it is answering. A senior U.S. engineer tests whether a user can reach another customer’s records through your assistant, retrieval layer, or connected APIs, then gives your team the evidence to fix the gap.
-
01 · The request
Customer A
Show my renewal terms.
Signed in, session holds customer_id = "acme"
No prompt injection
-
02 · Retrieval
search( index="contracts", query=embed(q), top_k=4, )filter=customer_id Never sent
-
03 · What came back
4 chunks, ranked by similarity
- acme/msa.pdfA
- acme/order-form.pdfA
- northwind/renewal.pdfB
- acme/sow-3.pdfA
-
04 · The answer
To Customer A
“Your annual renewal is $48,000, with an 18% discount.”
Source: northwind/renewal.pdf
Cross-customer exposure. Critical.
- Customer A The customer who asked
- Customer B The records they reached
Nothing replaces skill. Illustrative test, synthetic records. The model summarised what it was handed. The missing argument is the finding.
What could a user make it do?
See data they should not see
Test customer boundaries, sensitive information exposure, and access through retrieval and connected systems. Follow the request from the signed-in user to the records returned, including conversation history and shared knowledge bases where in scope.
Give instructions your application should not trust
Test direct prompts and instructions embedded in documents, retrieved content, and other supported inputs. Determine whether those instructions can redirect the application toward restricted data or actions.
Take actions they never had permission to request
Test agent tools, delegated permissions, and approval checks around connected workflows. An agent’s ability to call a tool should not give every user the authority behind it.
Turn an answer into another attack
Test how connected systems handle model output, including downstream injection risks. Evaluate resource abuse within agreed limits, with attention to the requests and workflows that can drive cost or disrupt service.
Model hosting, plugins, training data, and supply-chain components can be included where accessible and agreed. Revealing a system prompt is assessed for its actual impact, such as exposed secrets or a path across an access boundary.
Cross-Customer Retrieval
A retrieval layer that never filters on who is asking, so one tenant’s records answer another tenant’s question.
Indirect Prompt Injection
Instructions hidden in a document or a web page the application retrieves, and then follows.
Over-Permissioned Tools
An agent that can call a tool every user can therefore reach, with the authority behind it.
Secrets in the System Prompt
Keys and endpoints in the prompt, recoverable and worth something once they are out.
Output Trusted Downstream
A connected system that runs, renders, or stores model output without treating it as untrusted input.
Unbounded Tool Cost
Requests that drive expensive calls with nothing capping how many a single user can trigger.
A real test follows the whole request.
We start with your architecture, user roles, data sources, and connected tools. Then we test how an attacker could move between them, validate the impact, and show your team where the controls failed.
Agree the boundaries
01
Map the application and the access each role should have. Define the systems and workflows included in the engagement.
Test adversarial inputs
02
Challenge prompts, retrieved content, and supported inputs in the context of your application’s permissions.
Follow the impact
03
Trace what the application retrieves, returns, or changes. Separate unexpected model behavior from a demonstrated security failure.
Explain the fix
04
Document the path and prioritize the controls that need to change, with findings your engineers can investigate.
Scoping establishes test accounts, permitted actions, data handling, and operating limits before testing begins. Production agents need particular attention to writes, approvals, and potentially expensive tool calls.
The steps that produced the finding
Relevant inputs, retrieved content, tool calls, and application behavior, connected into an inspectable sequence.
The boundary that failed
What was exposed or changed and why the requesting user should not have been able to reach it.
Fixes for your application
Prioritized remediation tied to the affected permissions, retrieval logic, tool integration, or output handling.
An engineer who can explain it
The engineer who tested the application discusses the findings with the people responsible for fixing them.
Two Ways to Test Your AI
Start with the decision you need to make. We’ll help establish the AI scope and engagement terms that fit it.
An application that keeps changing
Raxis Attack
Discuss ongoing testing needs as models, prompts, data sources, and tool permissions evolve. Agree which AI components and changes belong in the engagement.
FAQ: AI & LLM Penetration Testing
Are you testing our AI application, or using AI to run a pentest?
This service tests the security of your AI application. A Raxis engineer evaluates how its model, retrieval systems, permissions, and connected tools behave under attack. The scope is the application you are building or operating.
Can you test our RAG application, internal assistant, or agent?
Yes. We scope testing around your users, data sources, retrieval logic, and connected tools. For an internal assistant, that may mean department or role boundaries; for a customer-facing application, it may mean separation between customers. For agents, we also consider permitted actions and approvals.
Does the scope include the web application and APIs around the model?
It can. We identify the application and API components needed to follow an AI request and agree which are included. If you need broader web application or API testing, we can scope that alongside the AI assessment so responsibilities and coverage are clear.
What access do you need, and can testing be done safely in production?
Access typically includes test accounts for relevant roles, application endpoints, and information about expected permissions and connected systems. Production testing depends on the environment and agreed limits. We discuss data handling, request rates, and actions that could change records or incur costs; higher-impact scenarios may need staging or a controlled test setup.
Can you test commercial, open-source, or fine-tuned models?
Yes. The application can use a commercial model API, an open-source model, or a fine-tuned model. Access and ownership determine how far testing can extend into hosting, model artifacts, or training pipelines. Testing your integration does not imply access to a model provider’s internal systems.
Do you retest after we fix the findings?
Yes. Once your team has made the changes, we retest the findings to confirm they are resolved, at no additional charge. For AI applications we agree up front what a resolved finding looks like, because model output can vary between runs and a fix should be judged on the boundary that failed rather than on a single response.
Who performs the testing?
Senior US-based Raxis engineers holding certifications such as OSCP and OSWE, testing AI applications as applications: their permissions, retrieval, and connected tools. The engineer who tests your application is the one who explains the findings. No outsourcing.
When should we test again?
Revisit the scope when changes affect what your AI can access or do: a new model, revised prompts, additional data sources, different retrieval logic, or new tool permissions. The timing and depth of testing should follow the change and its impact, alongside verification of fixes.