Enterprise data exposure often stems from "shadow AI," the use of unsanctioned personal accounts for company work. When an employee pastes sensitive material, such as contracts or product briefs, into a consumer-grade AI tool, that data leaves the organization’s controlled environment. While enterprise-licensed tools typically include contractual protections against using submitted data for model training, personal accounts offer no such safeguards, effectively moving proprietary information outside the boundary of corporate governance.
Forrester's 2026 top cybersecurity threats report names this pattern as one of the defining risks CISOs face this year. Personal AI agents and unsanctioned tools enter enterprises through browser extensions and inbox access, reaching data and taking action at machine speed, outside the visibility and governance security teams rely on. The report holds security leaders accountable for the exposure that follows, even though the tools creating it were never procured, reviewed, or sanctioned by the security function. The risk worth addressing is not AI use in general, but AI use that falls outside an enterprise's sanctioned tools and governance.
Sanctioned, enterprise-grade AI tools typically operate under contracts that exclude submitted data from model training and keep it within data handling terms the enterprise has already reviewed and accepted. Unsanctioned tools carry no such protection. When an employee submits text, code, or a document to a consumer AI account, often accessed with a personal login rather than a company-issued one, that content leaves the enterprise's controlled environment and travels to the provider's infrastructure to be processed under whatever terms apply to a free or individual account. Those terms frequently allow the provider to retain the content and use it to improve its models, and the enterprise has no visibility into, or control over, that outcome.
The risk does not stop at the original document. Once an unsanctioned AI tool processes a contract or a piece of code, the summary or answer it produces can still contain the sensitive details, even when the wording is different from the source file, and a data classification tool built to catch that specific document will often miss the rewritten version entirely. OWASP, the nonprofit that tracks security risks in AI systems, ranks this kind of sensitive information disclosure as the second-biggest risk facing production AI applications today. A trade secret does not need to be copied word for word to leak, since it only needs to be recognizable in what the AI tool returns.
The instinctive response to unsanctioned AI use has been to extend existing controls: block known AI domains at the network layer, add generative AI categories to an existing data loss prevention policy, and train employees not to paste sensitive material into public tools. Each of these measures has value, and none of them addresses the structural condition that creates the risk in the first place.
Network-level blocking assumes AI use happens through a small, identifiable set of domains, an assumption that breaks down as AI capabilities get embedded into browsers, productivity suites, and everyday SaaS tools employees already have legitimate reason to use. Data loss prevention systems built for file transfers and email attachments were not designed to inspect a prompt window or evaluate a paraphrased output for the presence of confidential content. Training addresses intent, but it does nothing for the employee who does not realize a customer list or a pricing model counts as sensitive, or who is simply trying to hit a deadline. All three approaches share a common limitation: they attempt to catch data on its way out, after it has already reached a system the enterprise does not control.
The more durable answer changes where enforcement happens rather than how aggressively it is applied after the fact. Instead of allowing data to travel to an AI model and then trying to inspect, filter, or recall it, the architecture can require the model to operate within the boundary where the data already lives. NIST's AI Risk Management Framework, in its guidance for generative AI, frames this kind of boundary control as a governance function built into how a system operates, not layered on as a monitoring tool after deployment. That framing matches what security and legal teams increasingly ask for: evidence that data never left the controlled environment, rather than a log showing that a violation was caught after the fact.
Kamiwaza's Distributed Data Engine applies this principle directly. Agents and models operate against data in the format and location where it already resides, whether that is a document repository, a structured database, or an internal knowledge system, without requiring that data to be extracted, copied, or transmitted to an external service to generate a useful result. When the model comes to the data instead of the data leaving to reach the model, there is no transit event for a blocklist to miss and no output to retroactively scan for a paraphrased trade secret, because the confidential material never crossed the boundary to begin with.
Bringing the model to the data solves the transit problem, but it raises a second question: what should that model be allowed to see once it operates inside the boundary? Pre-retrieval enforcement answers this by applying access policy before a document or record is ever pulled into a model's context, rather than filtering the output afterward. If a policy would prevent a human user from viewing a particular file, that same policy blocks an agent acting on that user's behalf from retrieving it in the first place.
Inherited entitlements extend that principle to the identity layer. Rather than granting an AI agent a broad service account or a hardcoded set of permissions, the agent operates under the same entitlements as the human user it serves, scoped to the specific task at hand. Kamiwaz uses Relationship-Based Access Control so an agent's reach never exceeds what the person behind it is already permitted to see. The combination of pre-retrieval enforcement and inherited entitlements means proprietary information is protected by the same access model that already governs the enterprise, rather than by a separate, AI-specific policy that has to be built and kept current on its own.
For security and legal teams evaluating a new AI tool, or auditing tools already in use, a short set of questions surfaces most of the exposure:
These questions reframe AI tool evaluation as an architecture decision rather than a compliance checklist completed after the fact. The organizations that ask them before deployment, rather than after an incident, are the ones that keep the pace of AI adoption intact without expanding the aperture through which their most valuable information can leave the building.
Most enterprises already have more unsanctioned AI use than their security and legal teams can track. Blocklists and training cannot close this visibility gap. A more resilient approach embeds data location and access enforcement directly into the architecture, providing a clear, defensible answer to where company data goes even as AI adoption grows. For CISOs and legal leaders, this architectural clarity simplifies the decision to approve new AI tools.