AI security review and prompt injection testing
A scoped review of your AI feature or assistant: prompt injection, data access, tool permissions and reliability, with findings your engineers can act on.
Scoped quote after a free discovery call.
Overview
An AI security review examines what your AI feature can read, what it can do, and what happens when someone feeds it hostile text. It is for SaaS teams shipping model-powered features and businesses using assistants connected to their own information. The focus is the application’s access, actions and failure behavior—not a promise that a model is risk-free.
ChuuniX provides AI consulting, development and security remotely worldwide and in the Philippines. We agree the testing boundaries before work starts and return findings your engineers can reproduce and fix.
What the review checks
The review checks how untrusted text interacts with your application’s information and permissions. Scope follows the feature’s real architecture: a read-only knowledge assistant needs different tests from an agent that can update customer records. We document what is included, what is excluded and the accounts needed to exercise those boundaries.
Prompt injection (direct and indirect)
We test hostile user messages and instructions embedded in documents, web pages, emails and tool output. Indirect prompt injection matters because retrieved content may look like useful evidence while trying to change the assistant’s instructions. Tests examine the consequences the surrounding application permits, rather than relying on a filter alone.
Data access
We examine retrieval, memory and logs against the users and customer accounts entitled to access them. RAG data leakage and tenant isolation tests ask whether a request can retrieve information belonging to another account. The application must enforce permissions before sensitive content reaches the model; a polite refusal after disclosure is insufficient.
Tool permissions
We compare each tool’s authority with its intended task. Read and write paths should be separated, unnecessary permissions removed and high-impact actions gated behind human approval. Testing considers both the proposed action and the checks performed by the system that executes it.
Reliability
We evaluate bad input, unavailable dependencies, unsupported requests and human escalation. The scope can include cost or rate abuse and unsafe handling of generated output. Reliability findings distinguish an answer that is merely unhelpful from behavior that exposes information, triggers an unintended action or fails without an appropriate hand-off.
How it maps to the OWASP Top 10 for LLM Applications
We use the OWASP Top 10 for LLM Applications as a methodology input, alongside the feature’s own threat model. The mapping below uses the published 2025 category names, checked October 2026. It helps organize coverage; it is not OWASP certification or a claim that every category is tested in every engagement.
| Review focus | Relevant OWASP category |
|---|---|
| Hostile user and retrieved instructions | LLM01:2025 Prompt Injection |
| Access to sensitive context | LLM02:2025 Sensitive Information Disclosure |
| Validation before output reaches other systems | LLM05:2025 Improper Output Handling |
| Tool authority and action approval | LLM06:2025 Excessive Agency |
| Retrieval permissions and isolation | LLM08:2025 Vector and Embedding Weaknesses |
| Answer reliability and resource abuse | LLM09:2025 Misinformation; LLM10:2025 Unbounded Consumption |
AI security review vs penetration test
An AI security review is not the same as a general penetration test. It concentrates on model-driven behavior, retrieved information and delegated actions. A penetration test examines the wider application and infrastructure. They complement each other; the agreed quotation makes clear whether any conventional application testing is included.
| AI security review | Penetration test |
|---|---|
| How hostile text changes model-driven behavior | How an attacker exploits the application and infrastructure |
| Retrieval, tenant boundaries and assistant memory | Application authentication, authorization and exposed services |
| Tools, output validation and human approval | Broader application and infrastructure attack paths |
| Findings limited to the agreed AI feature and tests | Findings limited to the agreed systems and test scope |
How the review works (process)
We establish the threat model, permitted tests and a fixed feature version before testing. A staging or test copy is the default. Live-system testing happens only with written client approval, with its boundaries agreed explicitly. Timeline scoped per engagement; we do not publish a duration that ignores the application’s complexity.
- Scope the feature: identify users, sensitive information, retrieval paths, tools and plausible misuse. Agree the questions the assessment must answer.
- Prepare the test environment: agree a fixed version, representative test accounts and appropriate test data. Confirm the authorized environment and permitted actions.
- Exercise the agreed scenarios: investigate direct and indirect injection, information boundaries and action permissions. Record evidence and limitations as well as failures.
- Review the findings: explain reproduction steps, impact and recommended fixes with the engineering team. Separate observed behavior from assumptions about untested paths.
- Fix and re-test: agree any implementation work and re-test the fixed issues against the relevant cases. Record what changed and any remaining limits.
What you receive (deliverables)
You receive findings ranked by impact, reproduction steps, a concrete fix for each finding and a debrief with engineers. The review includes a re-test of fixed issues. The report also states the feature version, testing scope and limitations so it can be interpreted in the right context.
Recommendations should be useful to the people changing the application: where an access check belongs, which permission is excessive, or which output needs validation. If you want ChuuniX to implement fixes, we agree that engineering scope separately. A successful re-test addresses the tested issue; it does not certify the whole system as secure.
Who it's for
SaaS product teams adding AI or about to release it
For SaaS product teams, we review AI features in the context of existing product permissions and customer boundaries. A chat interface, copilot, retrieval feature or agent needs tests that follow its data and actions, not only its conversational tone.
Businesses running assistants on their own documents and systems
You do not need to be a SaaS company. An assistant answering retail, property, hospitality or accounting questions can encounter private records and untrusted content too. We scope the review around the workflow, information and hand-off points that matter to your team.
Where we work
We work remotely with teams worldwide, and with businesses in the Philippines. Scoping establishes the environment, access arrangements and engineering contacts needed for the work. Remote delivery does not remove the need for clear written testing authorization.
Teams answering enterprise security questionnaires about AI features
A scoped review can provide technical evidence and a clearer account of tested boundaries. It does not guarantee acceptance by a buyer, completion of a questionnaire or a compliance outcome. We distinguish verified findings from controls or systems that were outside scope.
Want us to build it instead?
ChuuniX also builds assistants, retrieval systems and business integrations. Explore our AI integration services. Our AI consulting, development and security work defines what an assistant can access, which actions it can take and when a person steps in. If a feature is still being designed, AI development for SaaS teams can establish those boundaries before release. Building and reviewing are related engagements with explicit deliverables, rather than an assurance that our own implementation cannot fail.
Security guides
Read our AI security guide for Philippine businesses for regulatory context and our prompt injection testing checklist for application test planning.
AI Care Plan / support after launch
Post-launch support is available on a retainer covering monitoring, updates, moving to new models as they become available and security updates. The AI Care Plan defines what is included rather than implying unlimited changes or an always-available support team. Knowledge updates, model and provider changes, and security re-checks are agreed against the workflow your team actually operates.
Keep a named owner for source information, connected accounts and human approvals. We agree how incidents are reported, which changes need a new scope and what is re-tested before release. AI usage and support work are distinct parts of the engagement. Scoped quote after a free discovery call.
FAQ
What is an AI security review?
An AI security review examines what an AI feature can access, the actions it can take and how it behaves when given hostile or unreliable input. We agree the application and testing boundaries first, then provide reproducible findings, prioritized fixes and a re-test of fixed issues.
What is prompt injection, and why does it matter for my product?
Prompt injection is an attempt to steer a model through instructions supplied in user input or content it reads. It matters when that model can access private information or trigger tools. Testing examines whether hostile text can cross the application’s intended data or action boundaries.
Is an AI security review the same as a penetration test?
No. This review focuses on risks created by a model reading untrusted text, retrieving information and acting through tools. A penetration test addresses the wider application and infrastructure. They complement each other, and any conventional application testing needs to be explicitly included in the agreed scope.
Can prompt injection be fully prevented?
Filtering alone cannot fully prevent prompt injection. The practical goal is to limit what the model can reach and do, enforce access outside the model, validate outputs and require approval for consequential actions. A review tests those boundaries and records the risks that remain within scope.
What does the review check?
Coverage can include direct and indirect prompt injection, sensitive-data exposure, retrieval and tenant boundaries, tool permissions, output handling, reliability and cost or rate abuse. The agreed scope identifies which checks fit your feature, which accounts are used and which systems or behaviors remain outside the assessment.
Do you need production access?
A staging or test copy is the default, using an agreed feature version and suitable test accounts and data. We do not assume permission to test live systems. Live-system testing happens only with written client approval and an explicitly agreed environment, set of actions and testing boundaries.
What do we get at the end?
You receive a findings report ranked by impact, reproduction steps, concrete fixes and a debrief with engineers. It records the assessed version, scope and limitations. The review includes a re-test of fixed issues; implementation work is agreed separately rather than assumed to be included without limits.
How long does it take and how is it scoped?
Timeline scoped per engagement. We first establish the feature, data paths, tools, users, environments and authorized tests. That determines the effort and quotation. We do not publish a fixed duration that overlooks your architecture, and we agree any implementation work alongside the review’s included re-test.
We're not a SaaS company. We just use an assistant. Is this for us?
Yes. A business assistant connected to documents, an inbox, a store or internal records can encounter the same hostile text and permission problems. We scope the review to that workflow, what information it should reach, which actions it may take and where a person must review.