Keep the keys out of the prompt
The risk in a coding prompt is rarely the algorithm. It is what rides along: keys, connection strings and customer data in fixtures.
Not for long. A block moves AI use to places you cannot see. Allowing approved tools and explaining each stop works better.
A hard block on AI tools rarely works for long. It stops the traffic you can see and moves the rest to places you cannot: phones, personal laptops and home networks. The better question is not whether to block AI, but which data should reach which tool, and what a person sees when the answer is no.
A block is the first move for good reasons. The risk is real and the rules are clear. A customer list pasted into a chatbot has left the organization. Source code uploaded to a personal account is out of your hands. Legal wants a line drawn, and a blocked domain is a line anyone can point to.
It is also fast. One entry in a web filter and the problem appears to be solved. The dashboard goes quiet, and a quiet dashboard looks like control.
That quiet is the trouble. It tells you the traffic stopped on the network you watch. It does not tell you the work stopped.
People use these tools because they save time. A summary takes a minute instead of an hour. A first draft appears before the meeting starts. When the company tool is blocked, the deadline stays where it was, so the work moves.
It moves to a phone on mobile data. It moves to a personal laptop at the kitchen table. It moves to a new AI service the filter has not heard of yet, because new ones appear faster than any list can follow.
Now you have the same data in the same tools, with three things missing. You cannot see it, you have no record of it, and the person doing it has learned that security is something to work around. A policy that pushes careful people into hiding has made the risk harder to find, not smaller.
The opposite answer has its own failure. If everything is allowed and nothing is checked, you learn about the customer list in the chatbot months later, usually from someone else. A written policy that says "do not paste customer data" is a good start, but it relies on every person remembering it on every busy day. Good people make mistakes, and a tired one at the end of a quarter makes more of them.
So the choice between a wall and an open door is a false one. Both leave you without the thing you actually need, which is a decision about the data at the moment it moves.
The middle path has four parts, and none of them is exotic.
Allow the approved tools. Pick the services your organization has a contract with, and let people use them. A corporate account gives you retention terms, admin controls and audit logs. Saying yes here is what makes the rest of the policy believable.
Treat personal accounts differently. The same service can be safe on a company account and risky on a personal one. Blocking the whole domain breaks the approved tool; allowing it lets the personal account through. The policy needs to see the difference.
Decide on the content, not the destination. Most prompts are harmless. A question about formatting a spreadsheet needs no intervention. A prompt holding a customer list does. Sensitive values can be masked so the prompt still goes through, and the person keeps working.
Explain the stop when it happens. A silent block teaches nothing and invites a workaround. A short message that says what was found, and why it matters, teaches the policy at the moment it counts. Where the case is unclear, ask for a business reason instead of refusing outright, and keep the answer on record.
None of this needs to begin with enforcement. The first step is to find out what is happening: which tools, which teams, which accounts and what kinds of data. Run in monitor mode first, and you will know where the real risk sits before you change anyone's day.
That first view tends to settle the argument. Security stops debating AI in general and starts talking about one team, one tool and one kind of data. A rule written for that case is easier to defend, easier to explain and much less likely to send people to their phones.
From there, move in steps. Warn on the data that matters most, record the reasons people give, and block where the risk is plain. A policy that started in monitor mode can tighten without a new rollout.
Three questions show whether a block is working:
If the honest answer to any of these is no, the block is giving you a quiet dashboard, not control.
The goal was never to stop people using AI. The goal is to keep sensitive data out of the wrong place while the work carries on. Read how AI Data Security applies the same policy to prompts and uploads.