Shipmunk Start building
Security and privacy

AI app builder security, in plain terms

How Shipmunk keeps builds and keys safe: where the code runs, what a build can reach, how long things live and who can see what. Closed beta

An AI app builder writes code and then runs it. Good AI app builder security starts from that fact. The code is new, nobody has read it yet, and it runs on our machines. This page explains how Shipmunk contains it, and how we handle the keys and records that come with a build. If you want the build steps first, read how a Shipmunk build works.

What AI app builder security means at Shipmunk

We work to four rules. Each build is kept apart from every other build. A build only reaches the network through a gate we control. Everything that runs has a hard time limit. Keys and secrets are never shown back, and they are masked in the records we keep.

Shipmunk is in closed beta. The protections below are the ones in place today.

Each build runs in its own container

A build is one short-lived job with two containers. One holds the code the builder writes and runs it. The other is the gate. The gate holds the model keys and talks to the AI on the build's behalf. The container that runs your app's code holds no secret of ours.

  • Neither container runs as an administrator account.
  • The code container can only write to the project and temporary folders.
  • Before any code runs, the gate checks that the sandbox is in place. If it is not, the build is refused rather than run unprotected.

The network fence

The code container has no keys of its own. When the builder calls the AI, the call goes through the gate, which adds the key and records the call. Web requests from the build go through the gate's proxy too.

  • The gate refuses private, local and internal addresses, including the cloud address that hands out machine credentials.
  • A build can fetch public things it needs, such as packages and documentation.

Your app also does not get your real accounts while it is built. Payments, mail and other outside services are played by simulated stand-ins, and the plan names the settings your app needs without their values. The Shipmunk Sandbox explains how those stand-ins work.

Previews of a finished app run in a separate environment with no route to Shipmunk's own API.

Hard time limits on everything that runs

  • A build stops at one hour, and the platform ends its container shortly after if it has not exited.
  • A preview stays open for an hour at most each time you open it.
  • A streamed phone session lasts 15 minutes.
  • Each workspace has a daily cap on build minutes.

Previews that expire

When you open a preview, Shipmunk gives you a one-time link. It works once, for about a minute. The preview's gate turns it into a secure browser cookie for that preview alone. Without that cookie, the preview shows a blank page.

A phone preview opens in Expo Go on a private, hard-to-guess address. It works only while that preview is open. You can open a preview while the build is under seven days old. When the hour ends, the preview is deleted, and a regular sweep removes any that were missed. More on phone previews: building phone apps with Shipmunk.

Streamed phones are cleared between sessions

On a computer, you can try a phone app on a cloud Android device streamed to your browser. The stream link is tied to your session and its end time. When the session ends, Shipmunk closes the preview apps on the device and clears their data before anyone else can use it. If the clean-up fails, the device stays out of use.

Your model keys and secrets

You can bring your own key for a model provider. Only a workspace owner or admin can add, replace or remove one.

  • Your browser encrypts the key before it is sent. The key dialog shows the fingerprint of the encryption key, so you can check it.
  • Shipmunk's web API cannot decrypt it. It is decrypted only when it is used for a model call, and then held in memory.
  • The container that runs your app's code never gets your key.
  • Shipmunk makes one free call to check a new key before using it.
  • No screen or API response shows the key back. You see its last four characters.

Secrets masked in traces

Before a trace line is written, Shipmunk masks anything that looks like a credential. That covers API keys, access tokens, sign-in tokens, passwords in links, and values labelled as a key, token, secret or password.

What we keep and who can read it

Each build keeps a trace: the model calls, the builder's tool steps and the sites it contacted, masked as above. It also keeps evidence such as check logs and screenshots. These sit in private storage under your workspace.

  • Every database query is limited to your workspace by row-level rules.
  • Only the workspace owner or an admin can read build traces.
  • The owner can export everything the workspace keeps.
  • A deleted workspace can be restored by the owner for 14 days, then it is removed.
  • Anyone can delete their own account.

Sign-in and sessions

You sign in with email and password. You can turn on two-step sign-in with an authenticator app. With "Keep me signed in" off, your session lasts only for that browser session. Sign out ends the current device. Sign out others ends the rest. A password reset signs out every device.

What this page does not claim

We do not list compliance certifications here, and we do not claim any. If you have a question this page does not answer, read the Shipmunk FAQ. For live service health, see status.shipmunk.ai.

Build where the mess is contained.

Each build runs in its own container, behind a gate, on a clock.