What AI security testing covers
We test applications built on large language models, and the agents, tools, and data sources connected to them. Testing looks at what the model can be made to do, what it can reach through tools and integrations, and what data it can expose.
This service is for teams shipping AI features or deploying agents inside the business, such as support assistants, coding agents, internal copilots, and workflow automation. Security, engineering, and AI platform teams usually scope it together.
What is in scope
We agree the exact targets with you during scoping. An engagement can include any of the following.
AI agents
Agents that plan and take actions, including multi-step workflows, memory, and handoffs between agents.
MCP servers and tool use
Model Context Protocol servers and other tool integrations. Tool definitions, input handling, authentication on remote servers, and what each tool can do on the agent's behalf.
Prompt injection
Direct injection through user input, and indirect injection through content the model reads, such as web pages, documents, emails, and tool results.
Retrieval and data exposure
Retrieval pipelines, vector stores, and connectors. We test whether users can retrieve data they should not see, and whether system prompts or secrets leak.
Agent permissions
The permissions, credentials, and actions available to an agent compared with what its task needs, and whether high-impact actions require human approval.
LLM application testing
The application around the model: authentication, session handling, output handling, rate limits, and the APIs that serve it.
Techniques we test
Each technique is tested against the components agreed in scope.
| Technique | What it targets | What we check |
|---|---|---|
| Direct prompt injection | Instructions in user input | Whether the model can be made to ignore its instructions, reveal its system prompt, or call tools outside their intended use. |
| Indirect prompt injection | Instructions placed in content the model reads | Whether documents, web pages, emails, or tool output can steer what the agent does. |
| Tool poisoning | Tool descriptions and metadata from MCP servers | Whether a malicious or altered tool definition can change agent behavior or send data to an unintended destination. |
| Data exposure through retrieval | Documents and records the model can retrieve | Whether access controls on source data still apply when content is retrieved through the model. |
| Excessive agency | Permissions and credentials given to agents and tools | Whether an agent can take actions beyond its task, and whether approval steps can be bypassed. |
| Improper output handling | How the application uses model output | Whether model output can lead to cross-site scripting, injection, or unsafe code execution in downstream systems. |
How an engagement runs
We map the system with your team: models and providers, system prompts, agents, tools and MCP servers, data sources, and the identities each component uses. We agree the targets, environments, excluded actions, and contacts in the rules of engagement. An NDA is signed before you share details.
We test the agreed components with manual techniques and tooling, through the interfaces that users and connected content can reach. For agents that act on other systems, we agree which actions may run against test data and which must stop before execution.
You receive an executive report and a technical report. Each finding has a severity rating, the affected component, reproduction steps including the prompts or content used, and remediation guidance. Because model output varies between runs, the report notes how consistently each issue reproduced.
After your team applies fixes, such as changes to permissions, tool definitions, or guardrails, we retest the findings and confirm which are resolved.
What you receive
Each engagement produces the same set of deliverables, sized to the scope you agree with us.
Agreed scope
- Written scope covering targets, environments, and accounts
- Rules of engagement with test windows, excluded actions, and contacts
- NDA signed before you share details
Findings
- Each finding rated by severity
- Prompts, content, or tool calls used to reproduce each finding
Reports
- Executive report for leadership and stakeholders
- Technical report with reproduction steps for each finding
- Remediation guidance your engineers can act on
Retest
- Retest of findings after your team applies fixes
- Updated status for each retested finding
Testing depth
Duration depends on scope.
| Approach | What you provide | When it fits |
|---|---|---|
| LLM application test | User accounts and access to the application or API | You have a chatbot, assistant, or AI feature exposed to users. |
| Agent and tool assessment | Accounts, tool and MCP server configuration, and agent permissions | Your agents call tools, MCP servers, or internal APIs on behalf of users. |
| Design and configuration review | System prompts, architecture documents, and read access to configuration | You want a review before launch or alongside testing. |
| Combined assessment | All of the above | Agents have access to sensitive data or can take actions with business impact. |
Standards and methods
Testing is aligned with the OWASP Top 10 for LLM Applications and the OWASP Top 10 for Agentic Applications. Techniques are mapped to MITRE ATLAS where it applies, and terminology follows NIST AI 100-2 on adversarial machine learning.
The application and API layers are tested against the OWASP Web Security Testing Guide and the OWASP API Security Top 10. Findings can be related to the NIST AI Risk Management Framework for teams that manage AI risk at program level.
Common questions
Do you test the model itself?
Testing focuses on the system built around the model: the application, agents, tools, data sources, and permissions. We test how the model behaves inside that system. Model-level evaluations can be discussed during scoping.
Will testing trigger actions in connected systems?
Only within the limits in the rules of engagement. We agree which tools may run, against which data, and which actions must stop before they execute.
What access do you need?
User accounts for each role, access to the agent or application in the agreed environment, and documentation of the tools, MCP servers, and data sources it uses. System prompts and configuration are needed for grey box testing.
Do you test staging or production?
Either. A staging environment with representative, non-sensitive data is often preferred for agents that can take actions. We agree the environment with you during scoping.
How are findings shared securely?
We sign an NDA before you share details of your environment. How reports and other sensitive material are exchanged is agreed with your team during scoping.
Can you provide a letter for our customers?
We can discuss it during scoping.
How to prepare
List the AI features and agents in scope, the models and providers they use, and every tool, MCP server, and data source they connect to. Note which identities and credentials each agent uses.
Prepare test accounts and an environment with representative, non-sensitive data. Share system prompts, architecture notes, and any guardrails or approval steps already in place, and name a contact who can pause agents during testing.
