Short answer
An AI security test checks what an attacker can make your model do with your data, your tools and your users' permissions. Each finding is a proved path: an input the attacker controls, the instruction the model followed, and the outcome, such as a tool call, a leaked record or a bill.
What gets tested
Chat assistants, retrieval-augmented search, support and sales agents, coding agents, and any feature where a model reads text it did not write and then acts on it. The agents first learn what the feature is supposed to do and who is allowed to do what, then test whether the model can be steered past those rules.
Most serious findings in LLM features are ordinary access control failures reached through the model: a retrieval query that ignores the tenant, a tool that runs with a service account, a confirmation step the model can skip. That is why the same test also covers the API and web layer the feature runs on.
Where attacks enter and where they land
A model cannot reliably tell your instructions from text that arrives inside a document, a web page or a tool result. Each input below is a way in, and each outcome is something the test tries to cause.
Untrusted text in
- User chat and API input
- Retrieved documents (RAG)
- Web pages the agent reads
- Tool and MCP results
Where it lands
- Tool calls as the user
- Other tenants' records
- Rendered links and markdown
- Spend: tokens and paid APIs
- 1. Input
- Where the attacker's text entered: a chat message, a document in retrieval, a web page, a tool result.
- 2. Instruction followed
- What the model was steered to do, quoted from its own output.
- 3. Outcome
- The tool call made, the record returned or the cost incurred, and whose permissions it used.
- 4. Proof
- The requests and responses that reproduce it, replayed by a second agent.
- 5. Fix
- Where to close it: usually a permission, a tenant filter or a confirmation step.
OWASP Top 10 for LLM applications coverage
Every engagement covers the 2026 edition of the OWASP Top 10 for LLM applications. The right-hand column shows how each risk is tested.
| Risk | How Helix tests it |
|---|---|
| LLM01 Prompt injection | Direct injection in chat and API input; indirect injection planted in documents, pages and tool results the model reads |
| LLM02 Sensitive information disclosure | Two accounts and, where it applies, two tenants: can one retrieve or summarise the other's data |
| LLM03 Excessive agency | Steer the model into tool calls beyond the user's role, and past confirmation steps on actions that change state |
| LLM04 Supply chain | Inventory of models, plugins and MCP servers in the request path, with known issues and pinning checked |
| LLM05 Data and model poisoning | Content a user can submit that later enters retrieval or memory for other users |
| LLM06 Unbounded consumption | Bounded checks for loops, oversized context and paid tool calls a user can trigger without limits |
| LLM07 Misinformation | Answers that cite or act on retrieved content the user should not trust, where your product presents them as fact |
| LLM08 Hidden context exposure | Extraction of system prompts, tool schemas and secrets, and whether anything extracted is useful to an attacker |
| LLM09 Vector and embedding weaknesses | Tenant and permission filters on vector search; documents that rank for queries they should never answer |
| LLM10 Improper output handling | Model output reaching HTML, markdown images, links, SQL or a shell, including exfiltration through rendered URLs |
Agents, tools and MCP servers
An agent turns a prompt injection into an action. The test lists every tool the agent can call, what each one can change, and whose credentials it uses, then tries to make the agent use each tool on an attacker's behalf. For MCP servers that includes tool descriptions and results that carry instructions, tokens scoped wider than the user, and write actions with no confirmation.
Findings report the full chain: where the instruction was planted, what the agent did, and what it could reach. The fix is usually in permissions and confirmation, not in the prompt, and the report says which.
Why an agent platform tests agents
Helix also builds an agent orchestration platform where agents work on real systems inside sandboxes and a person approves what they produce. Keeping those agents contained is our own engineering problem, so the failure modes in this test are ones we design against every day.
The testing itself runs the way every Helix pentest does: separate agents for recon, testing and verification, sandboxed desktops, private inference, and a second agent that must reproduce a finding before it reaches you. See how a Helix pentest runs.
What to provide
- The features in scope and where users reach them: web, API, Slack, email, or another channel.
- Test accounts at two roles and, for multi-tenant products, in two tenants.
- The tools and MCP servers the model can call, and which of them change state.
- For a deeper test: system prompts, tool schemas and the retrieval configuration.
- Spend limits for the test, so consumption checks stay inside a budget you set.
Pricing and retesting
AI security tests are quoted after scoping, because the work depends on how many features, tools and data sources are in scope. If the LLM feature sits inside a web application or API you already need tested, scope them together so access control and prompt injection are covered in one engagement. Retesting is free and unlimited: mark a fix ready and the agents attack it again.
Frequently asked questions
What is AI security testing?
A penetration test of the LLM features, retrieval and agents in your product. You receive a report in which every finding is a proved path from an input an attacker controls to an outcome, such as a tool call, another tenant's data, leaked hidden context or cost, each with the request and response that show it and reproduced by a second agent. Retesting is free and unlimited.
How is this different from AI penetration testing?
The terms overlap. On this site, AI penetration testing describes how Helix runs every pentest: AI agents do the testing. AI security testing is what this page sells: testing the AI in your product. The same agents and the same reproduction step do both, and one engagement can cover a web app and the LLM feature inside it.
Do you test the model itself?
The test targets your application: the prompts, retrieval, tools, permissions and output handling around whichever model you use. Jailbreaks are in scope when they lead to a real outcome in your product, such as a tool call or a data leak. Benchmarking a model's general safety or offensive capability is a different kind of work and is not part of this service.
Do you need our system prompt and tool definitions?
No, but the test goes deeper with them. Without them the agents work black box from the product's interface. With the system prompt, tool schemas and permission model, the test checks each tool's authority directly and spends less time on discovery. The report states which mode was used.
Can you test MCP servers and agent integrations?
Yes. MCP servers and other tool integrations are tested for over-broad tokens, tool descriptions or results that carry injected instructions, missing confirmation on state-changing actions, and calls that run with more authority than the user who asked.
Are our prompts and data sent to OpenAI or Anthropic?
No. Helix Cyber runs open models on inference infrastructure we control, so your prompts, documents, findings and the test's own model calls are not sent to a third-party model provider. Your application's own model provider sees only the traffic your application already sends it.