An AI-built prototype should never touch production data, production credentials, customer accounts, shared networks or the main branch of a real repository. Give it synthetic data, its own throwaway keys and its own isolated environment, so a mistake in generated code stays small and easy to delete.
The reasoning behind the list
When you prototype with an AI coding tool, you are running code you did not write line by line, often written in minutes. The tool may also run commands on your machine. That is fine when the blast radius is small. It is risky when the prototype has the same access you do.
The rule of thumb is least privilege: give the prototype only what it needs to answer the question you are testing, and nothing else.
Five things to keep out of reach
1. Production data. Real customer records in a prototype create a privacy problem the moment someone shares a screenshot or a log. Use generated sample data. If a test truly needs realistic shapes, mask the values first.
2. Production credentials. Do not paste a live API key into a prompt or a config file for convenience. Create a separate key with the narrowest scope and a short life. If it leaks, you revoke it and lose nothing.
3. Your personal admin identity. Run the prototype as a dedicated test account, not as you. Your account probably reaches things the prototype has no reason to see.
4. Shared infrastructure. Do not deploy a prototype into the production cloud account or the shared Kubernetes cluster. A separate project or account makes cost, cleanup and incident response simpler.
5. The real repository. Build in a scratch repository or a branch that cannot deploy. Promotion should be a deliberate copy-and-review step, not a merge that happens because the demo went well.
A simple setup that holds
| Concern | Prototype setting |
|---|---|
| Data | Synthetic or masked |
| Credentials | Dedicated, narrow, short-lived |
| Identity | Test account, not a personal admin |
| Hosting | Separate project with a spend limit |
| Repository | Scratch repo, no deploy hooks |
| Network | No route to internal systems |
Make the rules easy to follow
People break rules when the safe path is slower. Keep a template repository with the right .gitignore, an example environment file and a README that says "prototype, not for real data". Starting from it costs nothing.
Add a standing rule for tools that can run commands: review what the tool asks to execute, and do not grant blanket approval in a folder that holds anything sensitive.
Checking what a prototype can actually reach
Teams are often surprised by what a prototype inherited. A scan of the repository and its dependencies shows what it pulls in, and an inventory of agents and tool connections shows what it can call. Safeguard provides dependency scanning, SBOM generation and asset discovery, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Can I use a copy of production data if I delete it afterwards?
Avoid it. Copies tend to land in logs, screenshots and chat history. Use synthetic data and mask values when you need realistic shapes.
What if the prototype needs a real third-party API?
Create a sandbox or test key with minimal scope, set a spend limit if the provider offers one, and revoke it when the prototype ends.
Sources
Last reviewed: 19 October 2026.
