Data Disclosure Assessment

Many teams pour effort into a carefully worded system prompt - the standing instructions that define the assistant's behaviour, tone, and guardrails - and then treat it as confidential, sometimes placing genuinely sensitive things inside it: business logic, the rules a user is not meant to discover, occasionally even credentials or internal details. But system prompts are inherently part of an LLM's context, and hence the LLM inherently has the power to exfiltrate it - which is why system prompt exfiltration is rated as the seventh-highest risk family in the OWASP 2025 Top 10 for LLMs.

We test how easily that system prompt can be extracted, and the answer is usually "more easily than you would like". The lesson is not merely to harden against extraction, though we will help with that; it is to stop relying on the secrecy of the system prompt at all. Anything whose confidentiality your security depends on does not belong in the prompt, because the prompt should be assumed readable. System prompt extraction is its own recognised risk for good reason: it hands an attacker the blueprint of how your application thinks, and therefore how to attack the rest of it.

More serious than the system prompt is external data - databases, knowledge bases, sensitive documents, API keys - that your organisation's agentic AIs have access to. We map the sensitive data actually reachable from your AI system and test whether it can be surfaced to someone who should not see it. The most common and serious failures live in retrieval. Where your system answers from a knowledge base, the retrieval layer must enforce the same access control your application does - a user's query should only ever retrieve documents that user is permitted to see. Time and again it does not: retrieval runs with broad privileges, and one user's question quietly pulls back another user's, or another tenant's, confidential documents. We test this isolation directly. We also test for cross-session and cross-conversation leakage and, where you have fine-tuned a model on sensitive material, for its tendency to regurgitate fragments of that training data verbatim. Underlying all of it is a single question we keep asking: should the model have had access to this in the first place? The cheapest data to protect is the data the model was never given.

Serving as a data exfiltration channel is not the only way an LLM can disrupt the security of your data. If an agentic AI system can write records rather than simply read them, or delete data entirely, the attack risks widen enormously. It transforms a compromised agentic AI system from a data leakage risk into a direct attack vector against your computer systems and operations. Moreover, if your organisation operates multiple agentic AIs, it can enable an attack to spread between them if one agent can write text to a file that another agent will read from - a kind of lateral movement for prompt injection.

Most forms of write access dangers come under the general topic of excessive tool permissions, which our Agent Security Assessment focuses on. However, our Data Disclosure Assessment nevertheless includes mapping the write-capabilities of your AI systems as well as their read capabilities, and for agent swarms and other multi-agent systems, we seek to test whether and how prompt injection can spread between them.

Retrieval-augmented systems introduce an asset many organisations forget to secure: the vector database that holds your documents as embeddings. It is easy to assume those embeddings are an opaque, safe representation of your text. They are not. Research has shown that embeddings can often be partially inverted - the original sensitive text reconstructed from the vectors alone - so an attacker who reaches your vector store may be able to recover its contents even without the source documents. We assess the exposure and access control of the retrieval store as the sensitive data repository it really is, and we examine it from the other direction too, since a corpus that accepts untrusted content is both a data-exposure risk here and an injection surface in our Prompt Injection Assessment.

You receive a map of the sensitive data your AI system can reach, the routes by which it can be made to disclose it, and the isolation failures - cross-user, cross-tenant, system-prompt, vector-store - that would let one person's question return another's secrets. Our remediation is built on least privilege for data: enforcing access control at the point of retrieval so that authorisation is applied before a document ever reaches the model, keeping secrets out of system prompts, protecting the retrieval store as the asset it is, and above all minimising what the model can see to what it genuinely needs. The broader discipline of protecting sensitive information across your organisation is the subject of our Secure Data Architecture offering; here we focus specifically on what your AI makes reachable. On its own, this assessment tells you how much a breach of your AI system would actually cost you.