Free to share, no vendor inside

Vibe-coding guidelines

Twelve for the people who build apps with AI assistants, and twelve for the IT and security teams beside them. Use them as they are, or make your own copy of the kit: a policy you can adopt, with the checklist, forms and a deck to brief your teams.

Copy the policy to Google Docs Read the guidelines

For builders

Anyone building apps with Claude Code, Codex, Cursor or a similar assistant, whatever their role.

Use an approved assistantUse the assistants your company has approved for work. Their terms cover company data. Ask before you use any other tool with work data.
Know what you can put in a promptKeep customer data, personal data, credentials and confidential material out of prompts unless the tool is approved for that kind of data. If you’re not sure, ask first.
Write down who it’s for and what it touchesBefore you start, write two lines: who will use the app, and which systems and data it reads or changes. That note decides how much review the app needs, and it starts the README.
Keep secrets out of everything you writeNever paste API keys, tokens or passwords into prompts, code, config files, chat or repositories. If a secret has been in any of those places, treat it as exposed and get it rotated.
Connect the approved way, with the least access that worksUse the company’s approved way to connect to other systems, so the credential stays with IT. Ask for read-only access first, and for write access once you can show you need it.
Build in small stepsBuild one screen or function at a time, and run the app between steps so you know which change broke what. Use version control, commit often, and check each commit for secrets.
Read what the assistant writesRead each change before you accept it, and ask the assistant to explain anything you don’t follow. Watch for dependencies you didn’t ask for and code that sends data somewhere unexpected.
Test with sample data and check inputsRun the app on made-up data before it touches real data. Check what people can type or upload before the app trusts it.
Put sign-in in front of anything you shareAn internal app always sits behind the company sign-in, never on an open link. Give access to the people who need it, and add more later.
Write a README and get a second pair of eyesSay what the app does, who owns it, what it connects to and what data it stores. Anything that writes to a system of record or touches sensitive data gets a review before you share it.
Ship the approved way, and keep IT postedDeploy the way your company has approved, never from a personal cloud account or with a personal token. Tell IT when the app picks up more users, sensitive data or a new system.
Own it, hand it over, retire itYou’re the owner until you hand the app to someone else. Plan the handover before you change roles, and switch off apps no one uses, along with their access.

For IT and security

The teams who set the rules and look after what runs.

Publish short, clear rulesKeep the rules to one page: which assistants are approved, what data may go in a prompt, and what needs review before an app is shared. People follow rules they can read in two minutes.
Make the approved way to ship the easiest wayTime the approved way against the workaround. If the workaround is faster, fix the slow steps first. Blocking assistants outright tends to push the work out of sight.
Tier apps by data and criticalitySet three or four risk tiers by data sensitivity and business criticality, and say what each needs. Keep the low tiers light, so the controls on the high tiers stay credible.
Name the events that trigger a re-reviewMore users, sensitive data or a new connection to a core system each trigger a fresh look at an app’s tier. Apps grow one step at a time.
Put sign-in in front of every appEvery internal app sits behind your identity provider, with access granted app by app. No public links for internal apps.
Hold credentials centrallyKeep credentials in a central secrets store or in managed connections owned by IT, never with individuals. Grant the least privilege that works, rotate in one place, and allow no personal tokens in apps.
Give every production app a named ownerNo app reaches production without a named owner. Write down who takes over when an owner moves on, and when an unowned or unused app gets retired.
Keep records you can answer fromKeep logs for every run, and a record of who deployed each app and who can open it. For any action, answer four questions quickly: who asked, as which identity, what it touched, who owns the app.
Know what’s runningKeep an inventory of AI-built apps: owner, tier, systems, data and where each runs. Start by asking each team, because much of it isn’t written down yet.
Make existing apps easy to findPublish a searchable list of what’s already built. People reuse before they rebuild, and you look after one app where you’d otherwise have five near-copies.
Scan code and dependenciesTurn on secret scanning for every repository and check dependencies for known problems. Require code review for apps in the higher tiers.
Roll out in stages, and watch the signalsStart with an inventory and the rules, then tiers and approved paths, then a low-risk pilot, then scale what worked. Track apps shipped the approved way, time to production and reuse.

Make it your company’s policy

Each one opens in Google Docs as your own copy. Fill in the brackets, add your logo, share it.

The policy

All 24 as MUST and SHOULD requirements, with scope, roles, risk tiers, exceptions, compliance and a sign-off block. Fill in the brackets and adopt it.

Make a copy or download .docx