Skip to content

Build an app with AI at work: start here

You can build tools for your own work today, on the approved tools, in your private sandbox, using public data or your own work files that hold nothing Confidential or Restricted. Use made-up or de-identified sample data instead of the real thing. Before you share an app, use other data, put it on the internet or let it change shared systems, get its risk tier through intake. And never break the five never-dos, which start with keeping restricted data out of unapproved tools and keys out of your app.

Who this is for

Staff who build vibe-coded or citizen-developed apps, automations or agents with AI tools (non-developers first), and the professional developers who build their own tools. You get what you can do alone, the five rules, and the ten steps in order. About 8 minutes.

This is the start of the builder handbook. About 41% of the US workforce reported using generative AI for work in November 2025 (Federal Reserve, April 2026).1 Many will try building with it. The aim here is to make the safe path the quickest one.

What can I do alone, and what needs a yes?

You can build alone when all of these are true:

  • You use a tool on the approved-tools list, signed in with your business account.
  • The app is private to you, in your sandbox workspace.
  • Its data is public, or your own work files. "Your own work files" means files you created, or exports you're entitled to use for your own job, that you don't share and nobody else relies on. If they hold customer details, HR records, pay, health, bank or card data or credentials, they don't count.
  • It doesn't write to anything shared, send messages to anyone else, or take actions outside itself.
  • Nobody else's work depends on it, and it doesn't score, rank or flag people (for example applicants or staff), even if only you use it.

Sandbox apps are time-boxed to 90 days and private by default (the Sandbox rules). You register your sandbox workspace once, with a one-time promise to ask counsel before collecting sensitive data, not each experiment.

You need a yes (intake) the first time you share the app with anyone, use other data, make it reachable without company sign-in, or let it write to a shared system, let others' work depend on it, or let it score, rank or flag people. The full list of triggers is under do I need intake. Automations, scheduled jobs and agents count as apps.

Where to get sample data. Ask the AI to generate invented records with the same columns and awkward cases as the real data, or export the real data and replace names, numbers and free text before you use it. Check a few rows by eye. Data handling explains the data classes.

Don't: paste real customer or staff data into a tool to \"see if it works\" (AP13)

Pasting sensitive data into tools that aren't approved for it is a documented failure pattern, and a common one (failure patterns). Use sample data until the tool is approved for that data class.

What are the five never-dos?

These apply at every tier, in your sandbox too.

(1) Never put restricted data into a tool that isn't approved for it. (2) Never put keys, passwords or tokens in an app's code, front end or prompts. (3) Never build or host a shared app on a personal account. (4) Never give an AI agent write access to live systems without a sandbox run first, a scoped credential and a restore you've tested. (5) Never turn on permission-bypass modes in coding agents.

A note on number 5: a mode in which a classifier or model, not a person, approves each action (often called "auto" mode) isn't human approval, so it counts as a permission-bypass mode. It's allowed only in a disposable sandbox with no credentials to shared systems and no real data.

In plain words:

  • Number 2: keys in the front end are a common way AI-built apps leak, next to missing data rules. Anything in the files the browser loads can be read by anyone who opens the app. Where to keep keys instead is on secrets.
  • Number 3 is about ownership. An app on your personal account leaves with you, and the business can't turn it off or recover its data.
  • Number 4 is conditional. An agent may read live systems if its credential can't change anything. Before it may write, it needs all three: a trial run on a sandbox copy, a credential limited to the actions it needs, and a restore you've actually tried. Agents with standing production access have deleted live data.2
  • Number 5 covers flags and modes that switch off the "ask me first" prompts (for example "auto-approve" or "yolo" settings). See safe permissions for AI coding agents.

Don't: turn on auto-approve or yolo modes (AP8)

Permission-bypass settings remove the last human check before the agent acts. People also click through prompts, so a scoped credential and a tested restore are what limit the damage (coding agents).

Don't: give an agent standing access to production (AP4)

An agent with standing production access deleted a live database in a documented incident.2 Give it a sandbox copy, a scoped credential and a restore you've tried.

Don't: put secrets in prompts, repositories or front ends (AP11)

A key pasted into a prompt or committed to a repository, or shipped in front-end files, is readable by others. Keep secrets in a secrets manager; see secrets.

Why check the packages the AI adds?

AI tools sometimes suggest packages that don't exist, and attackers register those names with malware inside. If your tool writes code, look up each new package on the registry's website before you accept it: it should have a real project page and some history. Don't install something just because the AI suggested it. The checks, the evidence and the reviewer's part are on the security checklist.

What are the ten steps from idea to sharing?

Each linked page shows "Step N of 10". If you build only for yourself, in the sandbox, you mostly need steps 1, 4, 5 and 6. The rest apply when you share.

  1. Start here. You're on it.
  2. Check your data. Which class is it, and is your tool approved for it? (Data handling)
  3. Get a tier if you'll share. Answer the six questions at intake.
  4. Write a spec. One page, before you prompt. (Write a build spec)
  5. Build in small steps with the starter prompts.
  6. Test. Real examples with expected answers, plus access checks. (Test your AI-built app)
  7. Document. The one-page app record. (Document your AI-built app)
  8. Run the V.E.R.I.F.Y. self-check before release. (Check an AI-built app before release)
  9. Go through the go-live checklist. (Make a vibe-coded app production ready)
  10. Change it safely and hand it over when you move on. (Change a worker-built app safely)

How much each step asks depends on the app's tier. The tier-by-stage table is the gate matrix.

What if I'm building an agent or automation?

An agent that holds credentials and acts for you counts as an app, and its identity, permissions and tokens go in the app record (modifier M3 in the tier model). Read MCP and agents before you connect one to anything shared.

Where do I get help?

Ask your champion or go to the office hours described in enablement and training. Ask early: a five-minute question about a never-do costs less than a leaked key. If your organization has no champions yet, ask IT who handles intake.

If you're a professional developer

The same rules apply to you, with these differences in practice.

  • Agentic tools. Use the tool's plan or ask-first mode for anything beyond a small change. Keep permission-bypass modes off, and give the agent a scoped credential, never your own login (coding agents).
  • Standing instruction files. Keep one source of truth in the repository for the conventions and security requirements your tools read (standing-instructions starter).
  • Small pull requests. Keep each change reviewable, with tests written first. AI raises the volume of code to review, so smaller changes matter more.
  • Review load. Don't approve what you haven't read. Builders review AI output more reliably when the process makes review visible and expected (A-021).
  • Your tool is an app too. A script you wrote for your team gets a tier, an owner and an app record like anyone's.

Next: verify, change and coding agents.

Assumptions and evidence

  • A-021 (Low for non-developers): Hypothesis. We expect builders to review AI output only when the process makes review visible and expected; test this by counting how many changes in your pilot ship with no recorded test run or self-check.
  • Evidence: government and vendor guidance, a Federal Reserve note on worker AI use (November 2025 data), and incident reports. No study of non-developer builders exists.
  • Facts on this page are as of October 2026.

  1. Board of Governors of the Federal Reserve System, Monitoring AI Adoption in the U.S. Economy (FEDS Notes), 3 Apr 2026, https://www.federalreserve.gov/econres/notes/feds-notes/monitoring-ai-adoption-in-the-u-s-economy-20260403.html [primary], accessed 2026-10-22. ↩

  2. The Register, Vibe coding service Replit deleted user's production database, faked data, told fibs galore, 21 Jul 2025, https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/ [news; draws on the affected user's own posts], accessed 2026-10-22. ↩↩