The ban that confesses
Samsung banned ChatGPT after engineers pasted source code into it. JPMorgan banned it. Apple restricted it. Verizon blocked it. Each ban made the news, and each was read as a strong security decision. It is the opposite. A ban is a confession: it says that the organisation has no way to let its people use a tool safely, and so it will pretend they are not using it at all. Because right now, while leadership debates the policy, the developers are debugging with Claude, the legal team is summarising contracts with ChatGPT and the finance team is forecasting in Gemini.
The sanctioned path, in one view
Three layers, one enforced path, every prompt logged. If a user can go around the policy layer, you do not have a security stack. You have a chat app.
- Prompt-injection attempts
- Blocked jailbreak patterns
- Out-of-scope queries
- Repeated refusals for the same user
- Model runtime bound to localhost, never to every interface
- Policy API restricted to internal service accounts
- Keys rotated; policy configuration encrypted at rest
- Interface never permitted to reach the model directly
You do not have a policy problem
You have a shadow-AI problem. The distinction matters because the two are fixed differently. A policy problem is solved by writing a better policy. A shadow-AI problem is solved by knowing what is actually in use, by whom, with what data, and by offering something better than the thing being used in secret. Most organisations cannot answer the first part. They have never measured how many AI services their estate talks to, so the policy is written for a population nobody has counted.
You don't have an AI policy problem. You have a Shadow AI problem.
Stop the ban. Start the build.
The fastest way to lose control of AI in an organisation is to forbid it. Engineers will use personal accounts. Marketing will paste into free tools. Compliance will not even know. The alternative is a sanctioned service that is faster than bypassing IT: a chat interface people will not resist, behind the single sign-on they already use, with a policy layer in the path and models that run where the data lives. The entry build does not need a GPU farm. We have run one on a single virtual machine with open-source components, and the point of it was never the models. The point was the path.
The path is the control
Three layers make a sanctioned AI service, and the order is the design. The interface is the only thing users see. The policy layer is the only thing the interface may talk to. The model runtime is the only thing the policy layer may talk to, and it is bound to localhost, never to every interface on the host. The policy layer screens every prompt and every response: secrets and regulated data on the way in; prompt injection and jailbreak patterns hidden in pasted content; requests for attack tooling; topics the service was not sanctioned for; and the answer itself before it reaches the user. Everything else in the design exists to make that path the only path. Put the interface behind single sign-on and multi-factor authentication. Restrict the policy API to internal service accounts. Rotate the keys and encrypt the policy configuration at rest. And never, under any pressure to make a demo work, let the interface reach the model directly.
If a user can bypass the guardrails, you don't have a security stack. You have a chat app.
Log every prompt like a firewall event
An AI service that is not logged is an unmonitored egress channel, and in 2026 that should be as unacceptable as an unlogged firewall. Forward every prompt, every response and every policy decision to the log platform and the SIEM you already run, and treat them as security events rather than product analytics. Four things are worth an alert from the first day: prompt-injection attempts, blocked jailbreak patterns, out-of-scope queries, and the same user being refused repeatedly, which is either a misunderstanding to fix or an intent to investigate. The same log is the evidence that the control existed and worked, which is the question the auditor and the regulator will both eventually ask.
The risk is the prompt
The uncomfortable truth that most boards have not yet heard is that the biggest AI risk is not the model. It is the prompt. It is the data your people paste into someone else's logs: the contract clauses, the customer's personal data, the unreleased financials, the patient records. A model can be evaluated, red-teamed and swapped. A prompt that left the estate is gone. That is why the sanctioned path starts with where the model runs and who sits between the user and it, and why the policy layer inspects the input before it ever considers the output.
Where to begin
Before the policy and before the build, measure. Take thirty days of outbound traffic from the estate and count the AI services it reached, the users who reached them and the volume that went. That number is your shadow-AI problem, and it is almost always larger than the policy assumed. Then stand up the sanctioned path for one team that is already using AI heavily, log it from day one, and watch the shadow traffic from that team fall. When it does, you have a strategy. Until it does, you have a ban.
Stop the ban. Start the build.
Krishna works at the intersection of cyber security, infrastructure, AI and enterprise risk, with a focus on engineering trustworthy and resilient technology foundations.
Follow on LinkedInThis perspective expands a post first published by the author on LinkedIn.
