AI & LLM Application Security
Test whether untrusted inputs can make your AI application expose sensitive data, misuse connected tools or act beyond a user’s permissions. We assess the security of your AI workflows and the systems they can reach.
Permission boundary
An AI feature can read external content, retrieve internal documents and call tools on a user’s behalf. Each connection creates a security question: what happens if the input is malicious, the retrieved content contains instructions or the requested action exceeds the user’s authority?
A support assistant should not reveal another customer’s information. A document-processing agent should not treat instructions inside an uploaded file as permission to change a record. A workflow should not accept a model-generated tool call as proof that the underlying action is authorized.
These are application security problems with AI-specific paths. Our assessments examine the controls around those paths and the impact if they fail.
Test how the application responds when instructions are introduced through direct user input or content it consumes. Depending on the workflow, this may include uploaded documents, retrieved material or tool responses.
We focus on whether manipulation can produce a meaningful security impact within the application’s actual access and capabilities.
Investigate whether prompts, retrieval behavior or connected functions can expose information to an unauthorized user. This includes data boundaries between users or tenants where those boundaries are part of the assessed system.
Examine how the application permits and executes tool calls. We assess whether manipulated inputs or model outputs can trigger inappropriate actions or misuse the permissions granted to the agent.
Test whether the application enforces the initiating user’s permissions when retrieving information or performing actions. A model’s request to use a tool should not replace the checks required by the underlying system.
Follow how untrusted inputs and generated outputs move between the model, application and connected services. We investigate where content is treated as an instruction, where assumptions about trust break down and whether a workflow can be redirected beyond its intended purpose.
Conventional penetration testing remains relevant: authentication, APIs and backend access controls still need to work. An AI-focused assessment adds tests for how model inputs, retrieved content and generated actions interact with those controls.
The objective is more specific than making a chatbot produce an unusual response. We examine whether the behavior exposes data, enables an unauthorized action or creates another security consequence in the system being assessed.
Where broader application coverage is needed, we can scope it alongside Web Application and API Penetration Testing.
This service is relevant when you are building or changing:
Useful assessment points include the introduction of a new tool, broader permissions, a new data source or a significant change in how an agent can act.
We agree which application features, users, tools and data sources are in scope, and what the system should prevent. We also agree the test environment and permitted actions.
We examine where inputs originate, what information reaches the model and how outputs lead to retrieval or tool use. This establishes the trust and permission boundaries to investigate.
We test relevant prompt-injection, data-exposure and authorization scenarios against the agreed workflow. Evidence records the observed behavior and the conditions under which it occurred.
We connect findings to the application behavior that made them possible. Recommendations address the relevant data-access, tool-permission or workflow controls, rather than assuming a prompt change alone resolves the issue.
The report provides evidence about the assessed configuration and observed behavior. It does not promise that every possible prompt or future model response has been tested.
Our auditors have encountered prompt-injection vulnerabilities during previous Web2 and Web3 security assessments. This experience informs a practical focus on how AI functionality interacts with application permissions, sensitive data and connected systems.
We assess applications and systems integrating AI. This service does not train foundation models, certify AI safety or evaluate a model’s general intelligence or quality.
Tell us what your AI feature can read, which tools it can use and what it is allowed to change. We will help define an assessment around the security boundaries that matter.
Yes. The assessment focuses on your application’s integration, data flows, permissions and connected functionality. Using an external model does not remove the need to assess the surrounding system.
Yes. Where included in scope, we assess agents that use tools, call APIs or take actions within software workflows. The tools and permissions available to the agent help determine the relevant scenarios.
No. Impact depends on what the application can access or do, and whether other controls prevent unauthorized behavior. We assess the observed consequences and the conditions required, not just whether the model follows an unwanted instruction.
Not necessarily. AI security testing focuses on the AI workflow and its boundaries. A broader application pentest may be needed to assess other features, endpoints and conventional vulnerabilities. We agree how these areas fit together before work starts.
No. AI behavior can vary, and changes to models, prompts, tools or data can change the security picture. The assessment identifies weaknesses and recommends controls within a defined scope and configuration.
The OWASP Top 10 for LLM Applications and the OWASP Top 10 for Agentic Applications describe relevant risk areas. If you need reporting mapped to particular guidance, discuss that during scoping. A framework reference is not a certification or a promise of testing every listed risk.
A description of the application, its users, the data it can access, its connected tools and the actions it can perform. We then agree the test accounts, documentation and other access appropriate to the engagement.