Skip to content

AI Security

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.

The real risk in a coding prompt is rarely the algorithm. It is what rides along with the code: an API key left in a config file, a connection string, customer data in a test fixture, an internal hostname. Protecting code from AI assistants starts with keeping those things out of the prompt, not with keeping developers away from the assistant.

What actually leaves

Picture a developer asking an assistant to fix a failing function. To help, the assistant needs context, so it reads the surrounding files. Those files were never written with an outside reader in mind. They hold a hard-coded token from a late-night fix, a sample record copied from production, a comment naming the server the code talks to.

Nobody decided to share any of it. The tool gathered it because that is how the tool works. An agent that can read a repository can read everything in that repository, and it can do so many times an hour.

This is why a written rule such as "do not paste secrets into AI tools" falls short. The developer did not paste anything. The agent picked it up.

Why banning assistants does not work

Some organizations respond by banning coding assistants outright. The ban is easy to announce and hard to keep. Developers are faster with these tools, and they know it. When the approved route is closed, the work moves to a personal account or a home machine, and now the same code reaches the same models with nobody watching.

A ban also leaves the most important question unanswered. It tells you nothing about which code matters. A marketing site and a core payment service are not the same risk, and treating them the same either slows everyone down or protects nothing.

Three things worth controlling

A practical approach has three parts.

Recognize what is in the prompt. Source code is its own category of data, and policy should be able to treat it differently from a marketing document. Secrets need their own detection: API keys, tokens and connection strings look like nothing else, and they can be found before they travel. Personal data in fixtures is caught the same way as personal data anywhere else.

Control the path. Agent hooks can check a prompt in tools such as Claude Code and Codex before it is sent. An AI gateway gives traffic to the Anthropic and OpenAI APIs one exit, with an audit log behind it. Copilot and Cursor need covering too, because developers rarely use just one tool.

Sort your repositories. Not all code deserves the same rule. Classing repositories as Red, Yellow or Green makes the policy match the risk. A Red repository holds critical code, so an assistant cannot read it at all. A Yellow repository can be used with care and a record. A Green repository is open to normal use.

What masking cannot do here

Masking works well for personal data. A name or an account number can be swapped for a label, sent to the model and restored in the answer. Code does not work that way. A function with its logic masked is no longer a function, so the assistant cannot help with it.

That makes the decision simpler. Mask personal values where you can, stop secrets every time, and for critical code the decision is to block. If the decision engine cannot be reached, a Red repository should fail closed, so that a network fault never quietly becomes an open door.

A policy developers can live with

The test of a policy is whether people still follow it on a busy Friday. A few habits help.

  • Allow the approved assistant on the company account, and let it run normally on everyday code.
  • Stop a prompt only when a secret or a critical repository is involved, and say why in one line.
  • Give the developer a way forward: remove the key, use the approved account, or move the task to a repository that allows it.
  • Record the event, so that a rotated key and a lesson learned can follow.

A stopped prompt is useful in itself. It often shows a key that should not have been in the repository in the first place, long before anyone outside finds it.

Where to begin

Start by looking. Find out which assistants are in use, on which accounts, and against which repositories. Then class your repositories, beginning with the few that would hurt most if they leaked. Turn on secret detection next, because that is where a single mistake costs the most.

Banning AI from engineering does not protect the code. It only hides how the code is being used. The goal is to keep the keys out, and to let developers carry on. Read how AI coding assistants are covered in GuardStance.

See it on your own data.

Book a demo