Run an amnesty first unless you already have an approved alternative that is as easy to use as the tool you would ban. An amnesty gets you an honest inventory. A ban without an alternative tends to move the usage out of sight, which makes it harder to find and harder to secure.
What each approach is good at
A ban is simple to state and simple to audit against. It works when the risk is severe, the tool is clearly out of bounds, and people have a sanctioned way to get the same job done.
An amnesty is a time-boxed offer: tell us what you use, with no consequences for past use, and we will either approve it or help you move off it. It works when you do not yet know what is in use, which is the usual situation.
| Situation | Better first move |
|---|---|
| You do not know what AI tools teams use | Amnesty |
| An approved tool exists and is easy to get | Ban the unapproved ones, with notice |
| A specific tool has a known serious problem | Targeted ban, immediately |
| Usage is mostly in prototypes and notebooks | Amnesty, then an approved path |
| Regulated data may have been sent | Amnesty plus a separate incident review |
The last row matters. An amnesty is about tool use, not a promise to ignore a data exposure. Say so in the announcement and involve legal early.
Run the amnesty in five steps
- Announce it for a fixed window, such as two weeks. Name the sponsor, ideally an engineering leader and not only security.
- Give a very short form: tool, purpose, team, what data goes in, how often. Five fields is plenty.
- Pair it with a search of your repos and logs so you can sanity check the answers. See how to find which AI services our code calls.
- Triage every entry into approve, approve with conditions, replace, or stop. Reply to each submitter within a week, because silence ends the program.
- Publish the approved list and the date of the next review.
What makes an amnesty fail
- Using submissions to discipline people. One example is enough to end trust in the program.
- Collecting the list and doing nothing with it.
- Ending the window without an approved path, so the same people go quiet again.
- Treating it as a security project only. Engineering managers need to own the replies.
What to do when it ends
Move to ordinary controls: an intake process for new AI tools, an approved list, and a regular search. OWASP's guidance on LLM supply chain risk recommends keeping an up-to-date inventory of components, and that includes models and tools that engineers add on their own. A short intake form is the step that keeps the list alive. See AI agent intake form questions for internal requests.
Keep the first approved list small. Ten reviewed entries that people actually use beat a hundred that nobody reads.
Quick check
How long should the amnesty window be?
Two weeks is a common choice. Long enough for people on leave to respond, short enough that the sponsor does not lose interest.
Do we need to tell legal?
Yes, before you announce. An amnesty may surface data handling questions, and legal should agree on how to treat them.
What if someone refuses to give up a tool?
Ask what job it does that the approved option does not. That answer is often the best input to your next approval.
Safeguard offers asset discovery and a free scan at gold.safeguard.sh/scan that can help you cross check what people report against what your code shows.
Sources
Last reviewed: 19 October 2026.
