Safety Rails for AI Builds

An AI assistant works fast. That is good, but a fast mistake is still a mistake. This page shows five habits that keep your site safe while an AI builds it. Set them up once, at the start of a project.

1. Build on Staging First

Do all your building on a staging instance. Move work to production only after you test it on staging.

• Bugs stay away from real people. Problems on staging do not affect your live users.
• Emails stay safe. A staging instance sends email only to the test recipients you set, with the real recipient shown in the subject line. Until you set test recipients, nobody gets anything.
• Outside services stay quiet. API call notifications are off on staging by default, so your tests do not trigger other systems.
• Use test data. Do not copy real customer data to staging. Use made-up data.

Your AI works on the instance that is selected, and the selection is remembered across conversations. Before any deploy, ask:

Which Insites instance is selected? If it is not my staging instance,
select my staging instance before you deploy anything.

See Staging vs. Production.

2. Connect GitHub So Every Change Has a History

When you connect GitHub, your AI saves each change as a commit in a GitHub repository. You can then see what changed, who changed it and when, and you can undo it.

Connect GitHub to my instance. Give me the install link, and tell me
which branch the instance will watch.

• When GitHub asks which repositories to allow, choose Only select repositories and pick one repository. If you allow all of them, the app may pick the wrong one.
• Only the watched branch deploys. A new connection watches main. Ask your AI to push unfinished work to another branch, such as feature/contact-form. Nothing deploys until that work is merged into the watched branch.
• CloudShell protects the watched branch on GitHub, so nobody can rewrite its history. On a free GitHub plan this only works for public repositories.

See Insites GitHub App.

3. Know How to Undo

With GitHub: Revert a Commit

Ask your AI:

Show me the last five commits. Then revert the last commit and check
that the deploy worked.

A revert adds a new commit that puts the repository back as it was before the commit you chose. It lands on the watched branch, so it deploys like any other change.

Note: A revert puts back the whole repository as it was before that commit. If you revert an older commit, every change made after it is removed too. To undo one change from the middle, ask your AI to make a new commit that reverses only that change.

Without GitHub: The 30-Day Copy

When your AI deploys a file directly, by upload or from a link, and that file replaces an older one, CloudShell keeps a copy of the older version for 30 days. Your AI has no CloudShell tool to restore that copy. If you need a file back from it, contact Insites support. This is one more reason to connect GitHub: with GitHub, you and your AI can undo a change yourselves.

Your AI can always show you what was deployed and when:

Show me the last ten deploys on my selected instance, with their status.

4. Keep Secrets Out of Your Code

An API key or a password must never sit in a page file or in your GitHub repository. Store it as a constant on the instance instead. CloudShell calls constants environment variables.

Store my maps API key as an environment variable called MAPS_API_KEY
on my selected instance. In the code, read it with
context.constants.MAPS_API_KEY. Never write the key itself into any file.

• Never show a secret on a page. Use secret keys only on the server side. A public key, made to be seen in the browser, is fine on a page.
• Never write a secret to the logs.
• Set it on every instance. Constants belong to one instance. A deploy does not copy them. Set the staging value on staging and the production value on production, so staging never talks to your live services.
• Names must match exactly. API_KEY and Api_Key are two different constants.

5. Check These Before You Let Your AI Go Ahead

Most AI assistants ask before they use a tool. Read each request. Stop and check when it wants to do one of these:

• Deploy to production. Make sure the same work passed on staging first.
• Push to the watched branch. That deploys automatically. Unfinished work belongs on another branch.
• Revert an older commit. It also removes every change made after that commit.
• Add a page with no policy. A page with no authorization policy is open to everyone. Ask who should see it.
• Add a file upload field. Uploads are public unless the field sets acl: private.
• Build a sign-in or a form with no limit. Insites has no built-in rate limit or lockout for your own sign-in pages. See Rate Limiting by IP.
• Put a key, a password or real customer data into a file. Use a constant for secrets, and test data on staging.
• Set constants in a migration. Make sure it checks which environment it runs on, or staging values can end up on production.

Who Can Do What

CloudShell can only do what your role allows. By default:

If a person only needs to look, give them Viewer.

Related

• Start Here: Build with AI
• Staging vs. Production
• Insites GitHub App
• About CloudShell
• Pre-Launch Checklist
• When Your AI Gets Stuck