Sensitive information disclosure is OWASP's name for an LLM application revealing personal, financial, confidential or security data to someone who should not see it. AI agents add new routes: they retrieve, remember, pass data to other agents and send it through tools. The fix is to scope what the agent can see to the case, and check what leaves.
What does OWASP say about sensitive information disclosure?
The OWASP Top 10 for LLM Applications lists sensitive information disclosure among its main risks. It covers personal information, financial details, health records, confidential business data, credentials and legal documents, as well as details of how the system itself is built. Disclosure can come from data the model was trained on, data supplied in the prompt, or data the application retrieves.
OWASP's mitigations, in substance: sanitise and minimise data before it reaches the model; validate inputs; apply strict access controls and least privilege to data sources; restrict what the model can retrieve; tell users how their data is used and kept; and avoid putting secrets in system instructions. For the definition alone, see what sensitive information disclosure is.
Who does it apply to?
Anyone building or operating an application on a language model that handles data worth protecting, which in regulated firms means almost all of them. The list is guidance, but disclosure by an agent is also a data protection matter: under GDPR, UK GDPR and similar laws, a leak by an agent is a personal data breach like any other.
How do agents leak data that chatbots would not?
A chatbot answers from what it was given. An agent goes and gets more, holds it across steps, and can send it somewhere. Each of those adds a route.
Over-broad retrieval. An agent that searches a shared knowledge base or document store may pull files about other customers or internal matters because they matched the query. If access control is enforced only by asking the model to behave, it will eventually fail.
Context bleed. Memory or context shared across conversations can carry one customer's details into another's session.
Disclosure to an unverified person. An agent that confirms account details to anyone who asks politely is a social engineering tool. Identity checks must happen before disclosure, not after.
Tools that send data out. Email, messaging and file tools can deliver data to the wrong place, whether by mistake or because injected instructions told the agent to. Our piece on OWASP prompt injection and agents that act explains that route.
Handoffs between agents. An orchestrator that passes the whole conversation to a specialist agent shares more than the specialist needs. Our piece on how agents share information without leaking it covers handoff design.
Logs and prompts. Prompts sent to a model provider and logs kept for debugging may contain personal data and need the same protection as the source systems.
How do scoping and output checks prevent it?
The two controls work at opposite ends. Scoping limits what the agent can see. Output checks limit what can leave.
Scope to the case. Retrieval should be filtered by the authenticated customer and the task, enforced by the data layer rather than the model. An agent handling a mortgage query for one customer should be technically unable to retrieve another customer's file.
Verify before disclosing. Account details are released only after identity checks appropriate to the channel and the data.
Pass the minimum. Handoffs carry the facts the next agent needs, not the whole history.
Check what leaves. Before any message or file is sent, check it for personal data that does not belong to the recipient, and confirm the recipient matches the case.
Limit outbound tools. Restrict where an agent can send data; free-form outbound email to any address is rarely necessary.
Take an illustrative case. An insurer's claims agent drafts emails to policyholders. A test finds that, for a claim involving two policyholders at the same address, the agent included the other policyholder's medical details in a draft. The fixes: retrieval scoped to the named claimant, an output check that flags health data about anyone other than the recipient, and a hold on any outgoing message the check flags. The incident is recorded, and the case is added to the agent's test set.
How do you meet OWASP's guidance for agents?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Least privilege on data | Retrieval scoped to the authenticated customer and task by the data layer | Access configuration; scoped query logs |
| Data minimisation | Agent receives only the fields its capability needs | Data map per capability |
| Identity verification | Disclosure only after channel-appropriate checks | Verification records |
| Output checks | Outgoing content scanned for personal data not belonging to the recipient | Output check logs; held messages |
| Outbound restrictions | Tools limited to approved recipients and channels | Tool configuration |
| Handoff minimisation | Only required facts passed between agents | Handoff records |
| Protect prompts and logs | Logs redacted or protected; model provider data use restricted by contract | Log policy; contract terms |
| Testing | Disclosure tests across customers, channels and injection routes | Test reports |
Excessive tool access widens every route above; see OWASP excessive agency.
What will a security reviewer, auditor or regulator ask?
- Could this agent retrieve data about a customer other than the one it is serving?
- What identity checks happen before it discloses account information?
- What checks run on outgoing messages, and what happens when one fails?
- What personal data is sent to the model provider, and what may the provider do with it?
- How would you know if an agent had sent data to the wrong person?
What does the OWASP entry not cover?
It does not set the legal test for a breach or tell you when to notify a regulator or customer; data protection law does. It does not define which data is sensitive for your business. For how the full OWASP list maps to agents, see how the OWASP Top 10 for LLM Applications applies to AI agents, and for binding rules, our guide to AI agent regulation mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Can a model reveal data from its training set?
It can, which is one reason OWASP covers training data. For most agents in regulated firms, the larger risk is data retrieved at run time, because that is where customer records live.
Is redacting personal data before it reaches the model enough?
It helps, but agents often need some personal data to do their job. Redaction should be paired with scoping, so the agent only sees the right customer's data, and with output checks.
Does an agent leak count as a personal data breach?
If personal data is disclosed without authorisation, yes, under data protection laws such as GDPR and UK GDPR. Your breach assessment and notification process should cover agent incidents.