Model-visible data is the information a model can read through prompts, retrieval, connectors, or embedded context. It matters because exposure happens when the model can access sensitive material, even if the user never intended to disclose it broadly.
Expanded Definition
Model-visible data is not just text a user types into a chat window. It includes anything a Large Language Model or agent can read during execution, such as retrieved documents, connector outputs, tool responses, cached conversation state, and embedded system instructions. In practice, the term describes the model’s effective reading surface, which may be broader than the user interface suggests. That distinction matters because the security question is not only who can see the data, but what the model can access and potentially incorporate into generated output or downstream actions.
Within AI security, model-visible data is often discussed alongside prompt injection, excessive tool scope, and overbroad retrieval permissions. The concept is still evolving in industry usage, so definitions vary across vendors and platform designs. NIST’s control language in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames access, least privilege, and data protection as governance obligations rather than model-specific features.
The most common misapplication is treating model-visible data as equivalent to user-intended input, which occurs when organisations ignore retrieval paths, shared connectors, and hidden context that the model can still read.
Examples and Use Cases
Implementing controls around model-visible data rigorously often introduces workflow friction, requiring organisations to balance model usefulness against tighter data scoping, connector governance, and more selective retrieval.
- A customer support assistant can read recent case notes through a retrieval layer, but it should not see full ticket history when only the latest incident is relevant.
- An internal AI agent connected to email and file storage may surface sensitive payroll details unless connector permissions are narrowed to the specific business task.
- A coding assistant using embedded repository context can expose secrets or proprietary logic if indexing includes files that were never meant for model consumption.
- A compliance copilot may summarise policy documents from approved sources, while excluding legal drafts that are still under review and not ready for broad model access.
- An AI workflow that invokes a cloud API through a tool call may expose account identifiers or tokens in the response unless output filtering is applied at the boundary.
For identity and access-sensitive deployments, the challenge is similar to the access discipline described by OWASP Non-Human Identity Top 10: the system should expose only the minimum identity, secret, and data surface needed for the task. In agentic systems, model-visible data must also be treated as an operational dependency, not a passive by-product.
Why It Matters for Security Teams
Security teams need to understand model-visible data because it determines the real blast radius of an AI deployment. If retrieval scopes are too broad, connectors are over-permissioned, or conversation memory is not isolated, the model may ingest confidential content that was never intended for that workflow. That can lead to privacy incidents, policy violations, secret leakage, and unplanned exposure of regulated data. The issue is especially acute where agents can chain tool use, because each additional read path expands the opportunity for data to be surfaced, transformed, or acted on.
Governance around model-visible data aligns with OWASP Agentic AI Top 10 and NIST AI Risk Management Framework, both of which reinforce the need for controlled context, traceability, and bounded system behaviour. The same principle also supports AI governance expectations in NIST AI 600-1 when generative systems interact with sensitive enterprise data.
Organisations typically encounter the consequences only after an assistant leaks restricted content into a response, at which point model-visible data becomes operationally unavoidable to investigate and contain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | Focuses on non-human access surfaces, secrets, and data exposure paths relevant to models and agents. | |
| OWASP Agentic AI Top 10 | Addresses agentic AI risks where tool access and context exposure expand model-visible data. | |
| NIST AI RMF | Defines governance practices for AI systems, including data management and risk controls. | |
| NIST CSF 2.0 | PR.DS-1 | Data protection and management controls align to limiting what sensitive data a model can read. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege control is directly relevant to limiting model and tool access to data. |
Restrict what the model can read by applying least privilege to identities, secrets, and connected resources.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
