Run these 3 checks before you let a Cursor live app touch real data

You are about to let a cloud agent build a live app, point it at a database, and hand a link to the team. That is useful until the app carries a credential, a wrong access rule, or public sharing of internal data. The publish step is where you decide whether the app is safe enough for real work.

Cursor lets teams build live apps from prompts and share the resulting link. Its cloud agents can scaffold the app, create a Postgres database when needed, put authentication behind Cursor SSO, and provision hosting. The deployment path covers new or existing repositories on Cursor Origin and GitHub, with GitLab support still pending. The speed is the point; who can see it is the problem.

Before publication, Cursor applies fixed-rule deterministic checks and AI-agent agentic checks to the app. They target secrets in app files or exposed credentials. The app is kept from publication until the security checks succeed and the user chooses to publish it. That is a good default, not a substitute for a publish gate you run yourself.

The publish step is where real data starts

When you publish, you select a unique domain and Cursor returns a live link. You can share the app with named people, groups, or the whole team, all behind Cursor sign-in. For Teams and Enterprise, public sharing is disabled by default, and a team admin can turn it on. Tidy is a setting, not proof. A default that is off today can be on tomorrow.

Team admins can inspect all apps and secrets, add custom security-review rules, approve a publish that the review blocked, and remove any app from production. If you are the admin, that is your control point. If you are not, build your checks on the assumption that the admin can see what you shipped and can pull the app.

Three checks keep real data out of the app

Run these as a repeatable gate before the app reaches production data. Each one is quick, and each one catches a different failure mode.

• Confirm SSO and database provisioning. Open the app's deployment or settings view and verify that sign-in is behind Cursor SSO and that Postgres was provisioned for the app. If the app needs a database, make sure it is the agent-created database for that app, not a shared dev database you forgot about.
• Add a fake credential and confirm publication is blocked. A failed check prevents publication until the issue is addressed. Put a fake API key or token in a non-sensitive app file, attempt to publish, and confirm the check stops it. If it publishes anyway, the review is not doing the job you need it to do.
• Test second-account access isolation. A published app can be restricted to named people, groups, or the full team, with access gated by Cursor sign-in. Sign in with a second Cursor account that should not have access, open the live link, and confirm it cannot reach the data or the app.

The checks catch different failures: wrong identity and data plumbing, a vendor promise that does not match your environment, and an access rule that looks right in the UI but fails when a second account tries to enter.

Credentials live in code until you prove otherwise

Most live-app incidents are boring: a credential left in a file, a connection string pasted into a config, or a secret copied into a place a reviewer would not look. Your planted credential is the test case. The first place to look is the app code and its config, not just the dashboard.

If your team uses code visibility, the credential question becomes operational. If your team does not, you are making a judgment call instead of running a check.

Keep the app's real credentials out of the repository and out of the app files. Treat any secret found in code as a failed check even if the automated review did not flag it. Publish only after the three checks pass, and only to the people who need the link.