Cursor Apps turns a cloud agent prompt into a hosted internal tool. Here's what its publish checks catch and what you still own

Published November 9, 20264 min read

Cursor announced the feature in its November 5 changelog, and the Apps docs fill in the details. It's available on every paid plan that includes cloud agents. We haven't built or published an app with it; everything below comes from those two pages.

How it works

You start a cloud agent and tell it plainly that you want an app. The docs give “Deploy this repo as an app” as an example prompt. It doesn't work in a local agent session.

• Code. Start from scratch, which creates a repo on Cursor Origin, or deploy an existing GitHub repo. The changelog says GitLab and other providers are “coming soon.”
• Hosting. Each app runs in a dedicated account for your team, or for you on an individual plan, isolated from other customers.
• Database. Cursor provisions Postgres if the app needs one. The docs don't name the provider or give limits.
• Secrets. If the app talks to your systems, such as a data warehouse, Cursor asks for the secrets. The docs say the agent never sees the values.
• Publishing. A tray lets you preview the app, pick its URL, and publish. Checks run, and you either get a live link or a list of what to fix.

For many teams, this is the fastest route yet from “I need a dashboard for this table” to a link a colleague can open. That speed is also the risk.

What the publish checks catch

Every publish runs four deterministic checks that can't be turned off, plus an AI security review that reads the app's files:

Admins can add their own rules to the AI review, but custom instructions can't remove the built-in checks. Admins can also approve a publish the review blocked, except when it flagged malicious code, hardcoded secrets, or exposed credentials.

That's a sensible floor. Leaked keys in agent-written code are a real and common failure, and the four fixed checks don't depend on a model's judgment.

What the checks don't cover

The deterministic checks are about secrets leaving in files. The harder problems with internal tools are about who sees what once the app is running, and the docs describe nothing that checks those.

• The app's own access rules. Cursor sign-in decides who can open the app. Whether a signed-in user should see every row the app can query is up to the code the agent wrote.
• What a secret can reach. The agent never sees a warehouse password, but the app uses it. If that credential can read payroll tables, every viewer of a team-wide app is one query away from them.
• Injection and logic bugs. The AI review may catch an unparameterized SQL query. The docs don't say what counts as “serious,” so don't assume it will.
• Drift after publish. The checks run at publish time. An app that's fine on day one can still call an API whose permissions change later.

The fix is the boring one. Give each app the narrowest credential that works: a read-only warehouse role scoped to the tables it shows, not the analytics team's shared login.

Sharing and API keys

Apps have three visibility levels:

Scripts, CI jobs, and Cursor's Grok Bot can call an app with an API key sent in the x-cursor-app-token header. Query parameters and cookies don't work. Personal keys open whatever their owner can open, and team keys open only the team apps they've been granted.

Requests made with a key are marked as automated and identify the key, not a person. That's good for audit trails, but treat a personal key like a session token, because anyone who has it can do what its owner can.

Rolling it out on a team

The admin controls are reasonable, and the docs say settings changes land in the team audit log. Before people start publishing, we'd decide these:

1. Turn Apps on deliberately. It's a team-level switch. Decide who owns the Apps dashboard before the first app appears in it.
2. Keep public apps off unless you have a reason. Turning them off later moves existing public apps back to team visibility.
3. Create team secrets yourself. Admins can create team secrets in the dashboard. Scoped, read-only credentials made by someone who knows the data beat personal secrets pasted in by app authors.
4. Write custom review rules for your own red lines, such as “block any app that queries tables with customer PII.”
5. Decide on API keys. If nobody needs scripts calling apps yet, turn key access off.
6. Review the dashboard monthly. Admins can see every app and secret and unpublish any app. Unowned internal tools pile up fast.

What Cursor hasn't said

The docs leave out pricing, quotas, resource limits, the Postgres provider, the framework the agent scaffolds, and how you read an app's logs. The terms say apps may be revoked or suspended “for policy violations or business, financial, or legal reasons,” and hosting is provided “as is” and “as available.”

That's fine for a dashboard you could rebuild in an afternoon, and a poor fit for anything a process depends on. Prefer deploying from a GitHub repo you control, so the code survives if the hosting doesn't. Our Cursor overview covers the rest of the editor and its cloud agents.

Sources

• Cursor changelog: Build live apps (November 5, 2026): launch, publish flow, checks, admin controls, and availability.
• Cursor docs: Apps: hosting, secrets, sharing levels, API keys, the four deterministic checks, admin controls, and terms.