Find out whether your LLM app is safe — beyond the chat box.

It tests the language model and its surroundings against the OWASP Top 10 for LLM Applications, 2026 edition, using the OWASP AI Testing Guide v1's numbered cases. Access decides how much it reaches. From a login and a chat box, one entry closes (LLM10 Improper Output Handling), six are half-answered, and three are not reached: LLM04 Supply Chain, LLM05 Data and Model Poisoning and LLM09 Vector and Embedding Weaknesses. That count is our reading, not a published figure.

Because browser and chat-UI output is visible from the client, while the other nine depend on facts outside the conversation: inventories, training data, database access. Six of them can be tested only in part. Direct prompt injection needs nothing, but indirect injection needs a place to plant content (AITG-APP-02 starts by crafting the payload's location).

Because a test against a defense nobody has read gives a number OWASP tells readers to reject. Mitigation 11 of LLM01:2026 asks for the full defense specification to be disclosed to testers, citing a 2025 result of "static attack success near zero while adaptive attack success exceeded 90% for most of 12 recent defenses". Without the real system prompt, an extraction also can't be confirmed or graded under LLM08:2026. We ask for text and configuration, never keys, secrets or console access.

On its own, usually not. Microsoft doesn't count reconstructing a service's own prompt as a vulnerability, and Google's AI vulnerability reward program treats system prompts and training corpora as almost always non-confidential and out of scope (both read on 10 September 2026; our wording). OWASP's LLM08:2026 grades such findings: informational if the hidden context holds no secrets and no security-relevant logic, medium for internal rules, filtering criteria or workflow logic, high for credentials or authorization that relies on its secrecy, critical if disclosure leads to remote code execution or broad data exfiltration. The finding is the secret in the prompt, not the prompt.

Not from the outside. LLM09:2026 records that published attacks reliably achieve high success rates with a handful of poisoned documents, even in corpora of millions, so a clean chat-box probe proves nothing. Without the access AITG-APP-08 needs (the LLM09 row above), LLM09 is marked not reached, with the missing item named and no conclusion drawn. OWASP says vectorless retrieval (BM25-only or LLM-native tree navigation) inherits the non-geometric risks but has no LLM09 attack surface.

Only single requests: large-context abuse and reasoning-loop exhaustion (LLM06:2026) take one request each, and AITG-INF-02's second payload is one oversized prompt. AWS lists request flooding among prohibited activities, Microsoft prohibits denial-of-service testing and network-intensive fuzzing, and SecWiz performs no denial-of-service, load or flood testing. Billing or agent records answer the cost question.

A contract, signed before the corpus is shared. Section 8(2) of the DPDP Act, 2023 provides that a Data Fiduciary may engage, appoint, use or otherwise involve a Data Processor to process personal data on its behalf, for any activity related to offering goods or services to Data Principals, "only under a valid contract". Section 8(1) keeps the Data Fiduciary responsible, section 2(x) defines processing to include retrieval, indexing, storage and use, and section 2(k) defines a Data Processor as any person who processes personal data on behalf of a Data Fiduciary. We assert nothing further (see our DPDP Act compliance page). Legal review makes such a scope slower to start.

A coverage ledger showing the access each entry was tested at, and findings with trigger, response, CVSS v4.0 score and fix. Hidden-context findings say whether the extraction was confirmed; indirect-injection findings show where the payload was planted and how it was retrieved; disclosed defenses are named. Untested entries are listed, each with the missing access named and no claim they are safe. Retest included. We sign the ledger and findings; you sign the access decisions and scope. SecWiz is not a CERT-In empanelled auditing organization, so where an empanelled auditor is required, the audit must come from one.