The dashboard opens. The sign-in screen works. A colleague can finally use the little tool that used to live on one laptop. Then comes the question that a working link cannot answer: can that colleague see only their own records?

Cursor's November 5 Build Live Apps announcement puts code generation, a database, authentication and hosting in one workflow. Its cloud agent can prepare an app from a request, using a new repository or an existing GitHub project. Publication remains an explicit action. The feature is available on paid plans with cloud-agent access, not as a local-agent deployment path.

The interesting boundary is inside that apparent simplicity. Cursor sign-in decides who gets through the front door. The app still needs to decide what an admitted caller can do.

One door, different callers

The current Apps documentation lists invited-person, team and public visibility. Public means anyone with the link. Teams and Enterprise have public sharing disabled by default, with an administrator able to enable it. Individual plans can also share publicly. These distinctions matter before real customer or employee data enters a prototype.

There is another entrance for software. Private and team apps can accept a Cursor API key through the documented request header. Personal keys can open the apps their owner can open; team keys open only the team apps they have been given access to. A disallowed key receives the sign-in redirect.

Cursor says these requests are marked as automated and identify the key, never a person. That is useful attribution, but it is not a claim that an app automatically knows which customer record a script should receive. Anyone building an app around a signed-in person's identity needs to examine the automated path separately.

What the publish check actually checks

Cursor documents four checks that always run before publication: blocking secrets in app files, blocking credential files, excluding .env files and excluding source maps. An additional AI security review reads the files and can block serious problems. Administrators can add rules without removing the built-in checks, and can approve some blocked publications, except for malicious code, hardcoded secrets or exposed credentials.

Those are specific controls, not a published guarantee about every access decision. TechRepublic's November 6 coverage makes the same practical distinction: testing with differently privileged accounts still matters. GigSoul has not deployed an app or measured the review's detection rate. This is an account of the documented release, not a security test.

Test the record, not only the link

For a first trial, use sample data with an obvious ownership boundary: two fictitious users, each with a different record. Check the result as the creator, an invited viewer and a viewer who should have no access. If automated access is needed, repeat the relevant task with a deliberately limited team key. Confirm both the allowed read and the denied read.

That is a proposed acceptance test, not a report of a defect in Cursor. It asks a narrower question than whether the page loads or the publication review passes. A sales dashboard can be reachable, attractive and still return the wrong slice of data.

Cursor has shortened the trip from an idea to a hosted app. Before handing over the link, make the next trip explicit: from an identified caller to the particular records that caller is allowed to use.