The risk model used by many organisations is still inbound-only: thinking about how adversaries use AI to attack, how deepfakes undermine authentication, and how phishing evades detection at scale. That threat model is accurate. It is also, for a significant proportion of organisations, the less urgent half of the problem.
The more immediate and harder-to-contain exposure comes from the other side.
From the inside
Employees submitting work to public AI tools are transmitting data outward, to third-party systems, under terms of service that typically reserve broad rights over submitted content. Kiteworks research published this week found that 83% of organisations lack automated controls to prevent sensitive data entering public AI tools. That is not a forecast. It describes the current state.
The framing problem matters because it determines where governance energy goes. Organisations that treat AI exclusively as an inbound risk invest in detection and response: monitoring model outputs, auditing outputs, and red-teaming deployed systems. Those are legitimate investments. But they do nothing to govern what leaves the organisation through the prompt window. The data has been reviewed before any output is produced.
AI chat interfaces are designed to remove friction from the interaction. That is what makes them feel like search engines, even when they are sending data to a third party. When a developer pastes code or a legal analyst submits a contract, the transfer can happen without an alarm, a DLP rule, or an audit entry.
Why this gap has grown
Understanding why 83% of organisations have this problem requires tracing the history of the controls that exist, not the ones that do not.
Data loss prevention, in its mature enterprise form, was designed in the era of email and thumb drives. It works by identifying known patterns such as credit card numbers, national insurance formats, and document signatures matching known classification labels, then blocking or flagging their transmission. That approach works for structured data moving through inspectable channels.
However, a prompt lacks these properties in the obvious form of a data label. Source code has no standard regex pattern. A strategy document pasted as plain text is indistinguishable to a legacy DLP rule from any other block of text.
75% of employees using AI for work tasks when only 14% have formal AI policies – that is a significant blind spot.
Cloud Access Security Brokers offer partial mitigation. CASBs can block access to specific domains or enforce authentication requirements for cloud applications, but they were not originally designed to parse the meaning of the content that traverses them.
This is why the Shadow AI problem is structurally different from the Shadow IT problem that preceded it. When employees used personal Dropbox accounts for work files, the risk was storage: data sitting on a server outside your organisation, generally static and, in principle, recoverable if the account was identified and closed.
When employees submit work to a public language model, the risk is absorption. The data is processed, tokenised, and potentially incorporated into system logs or model fine-tuning pipelines.
There is no recovery mechanism. Anthropic’s $1.5 billion copyright settlement set a precedent: a price can be set for data absorbed without consent. Organisations whose employees have been submitting proprietary content to public models for years are, in some sense, already on the wrong side of that logic.
What this exposure looks like in practice
Like trying to put toothpaste back in the tube, once your information has been ingested into the model, it’s never going back in.
This is no longer an abstract risk. In most organisations, sensitive data is already leaving through scenarios that no control can see.
Scenario one: proprietary code
A developer uses a public model to debug a proprietary algorithm. The code submitted includes the specific implementation choices that differentiate the product from its rivals. No alert fires. No log entry appears in the SDLC tooling. The IP has left via a channel that entirely bypasses code repository controls.
Scenario two: supplier contract
A procurement analyst submits a supplier contract to a public model for summarisation before a meeting. The contract contains commercially sensitive pricing, exclusivity terms, and strategic intent. The model returns a useful summary. The data transmitted is now subject to the provider’s retention and use policies, which the analyst did not read and the organisation has not reviewed.
And so it goes on…
Research this week suggests 84% of AI web tools have experienced at least one data breach. The exposure is not only what organisations are transmitting deliberately. It is also what the defaults of many tools transmit automatically.
Beware the regulators
With the EU AI Act’s governance obligations coming into effect, an organisation that cannot answer whether customer PII has been transmitted to an external model provider is not in a strong position. For most organisations in that 83%, the honest answer is that they do not know.
Incidents bring these scenarios to life
The PromptLock and LunaLock incidents reported in this edition are not isolated curiosities; they probe exactly this gap, and the results are worrying.
PromptLock demonstrates a more fundamental shift. Perimeter monitoring of AI API calls becomes irrelevant when the model is running on the endpoint itself. The control boundary has moved from the network to the device.
LunaLock exposes the harder problem: once data has left through an AI channel, the harm may be permanent. There is no simple way to put it back.
The same logic applies to proprietary source code, client contracts, or strategic planning documents. If that data was already transmitted to a public model, the 83% egress blindness figure makes that plausible for many organisations. A threat actor claiming to possess the data and threatening to misuse it therefore faces no credibility problem.
The organisation cannot rule it out. That asymmetry, between the attacker’s confidence and the defender’s uncertainty, is the leverage point. It exists because the egress channel was never mapped.
Both incidents become much easier to execute and harder to refute in organisations without egress visibility.
What we need to do differently
The design shift required is not technically complex. The difficulty is in the ownership decisions that must precede the technical choices, which have been deferred over the years in most organisations.
A tiered access model is the starting point. Public models such as free-tier ChatGPT, public Claude, and Gemini without enterprise agreements should be treated as categorically unsuitable for any work involving proprietary data, regulated information, or commercially sensitive material.
It is easy to state this as policy. Most policies I see say the same, but policy requires enforcement. Browser extension controls, network-level filtering, and endpoint management tools can block specific domains or flag submission attempts for review. Without enforcement, the policy is a statement of preference, not a control.
The middle road paid-for models (personal or enterprise) where data retention terms are contractually specified, and zero-retention clauses are available.
These are materially different from their public or free equivalents, but organisations must read and verify the small print.
The third tier is sovereign or local deployment: models running on organisation-owned infrastructure, using open weights or auditable architectures such as Switzerland’s Apertus, released this week by EPFL, ETH Zurich, and CSCS. This tier is appropriate for genuinely sensitive IP: source code for core products, strategic planning materials, regulated data that cannot leave the organisation’s infrastructure under any circumstances. However, this comes with costs, not least the compute cost.
Contextual DLP is what makes tiered access functional rather than performative. Legacy DLP matches patterns. Contextual DLP parses intent by distinguishing source code from prose, identifying a legal brief from a marketing email, and recognising a supplier contract from a general document.
Several enterprise security vendors have production implementations. The failure mode if this capability is absent is not weak DLP. It is no DLP at all for the organisation’s highest-volume outbound AI channel.
Agentic systems move the problem from information exposure to delegated action.
An assistant returns text, where as an agent can send your email, modify your code and even move your money.
Any deployment with that level of access needs a policy boundary defining which actions require explicit human approval.
Otherwise, the human-in-the-loop becomes a slogan rather than a control.
For a structured set of questions to take into those ownership conversations, David Hawks’ AI Trust and Security Questions for CIOs provides a practical starting point: which models hold what data, under what contractual terms, with what deletion rights, and who is accountable when the answer changes.
Put this into practice
Use The Irreversibility Trap checklist to test whether your organisation can prove provenance, permission, visibility, containment, and recoverability before sensitive data enters an AI system.
Why all this matters
The real governance failure is not that AI can act on organisations. It is that organisations still cannot see what they are sending to AI, under what terms, or who owns the decision.
That gap is not closing through awareness. The proportion of employees using AI for work tasks continues to rise while formal policy coverage remains at 14%.
The productivity incentive is strong. The individual employee has no reliable mechanism to distinguish a safe prompt from an unsafe one without organisational guidance and technical support. The gap widens with every quarter of AI adoption that outpaces governance.
The sovereign AI moves visible this week are best understood not as product launches but as answers to a liability question. Both Switzerland’s transparent model and Microsoft’s internal capability development are attempts to bring the model, the data, and the accountability into the same organisational boundary. That is, at its core, a trust architecture decision.
Organisations that rent their intelligence from third parties and have not mapped what leaves through the prompt window have answered a different question. They have decided, implicitly, that the productivity gain justifies an exposure they cannot currently measure. That may be the right call in some cases. It is not a decision that most governance frameworks have made explicitly, with named ownership, documented terms, and a defined review cycle.
The controls can be built. The harder question to answer is who owns the outbound channel, which is why ownership is the right place to start.
