Building internal tools with AI: who gets to see what

What Cursor's Build Live Apps does

Cursor, an AI coding platform, announced it in its changelog: you describe the app you want, one of its cloud agents writes it and, if needed, sets up a Postgres database, puts access behind Cursor sign-in and provisions hosting. When you publish, you pick the address and get a link. Its documentation mentions dashboards, portals and microsites among the uses, and each team or individual user gets its own hosting account, isolated from the rest.

Before anything is published, Cursor runs four fixed checks (exposed keys and credential files, among others) and an AI security review; nothing goes live until they pass and you choose to publish. Private and team apps require signing in to Cursor; on individual plans they can be opened to anyone with the link, while on team and enterprise plans that is switched off unless an admin turns it on. It is available on all paid plans that include cloud agents. The New Stack adds a caveat: it is unclear how reliably those checks catch misconfigured database permissions or access controls, and it advises closer scrutiny if the app connects to sensitive systems.

Nacho's jobs board

Imagine Nacho runs a renovation company with two crews. Every Monday he hands out the jobs by phone, notes missing materials in a spreadsheet and keeps progress photos on his mobile. On an ordinary Tuesday, one foreman turns up at a flat without the key and another buys tiles that were already on order.

That evening, Nacho describes what he needs: a list of jobs with the address, the crew, the materials still to come and progress photos. The next day he has a working link, leaves it open to anyone who has it and sends it to the group chat. It works so well that he forwards it to the plumber he subcontracts too. What he has not asked himself is what each person sees: the plumber logs in and finds every client's address and phone number, and where each key is collected.

Why does an internal tool grow without anyone thinking about access?

Because whoever builds it is thinking about the problem they want off their plate, not about who will log in. At first two trusted people use it and everything feels private. Then a new foreman arrives, a subcontractor, someone from the accountant's office, and the link gets passed around. Nobody decides to open it up. It just opens up.

Until now, a development team sat between the idea and the tool, asking about roles and permissions. With apps published straight from a description, that step gets shorter, and the person describing the app has to ask the question instead.

A link that reaches the wrong people

An internal tool tends to end up holding the most sensitive parts of a business: addresses, phone numbers, prices, sometimes how to get into a client's home. If everyone with the link sees the same thing, someone who only needed to know which job to go to can browse everyone's details. Fixing it later costs more: you have to take access away from people already using the app and, if it comes to it, explain to clients what happened. And if the data is personal, protecting it is still your company's responsibility, whoever wrote the code.

What should you decide before building your first internal tool?

The tool can come from a description; access is something you should decide yourself, with pen and paper, before you write a word of the brief.

• List who will use it: you, the office, each foreman, outside people. Next to each role, write what they need to see and what they do not.
• Start with test data or no client data at all, and add it once you know who has access.
• Share the app with named people, not through a public link. Go back to the list of who has access every so often.
• Ask in your description for each role to see only its own records, then check: sign in as a foreman and look at what comes up.
• If the app will connect to your invoicing software, your online shop or other company systems, have someone who knows security review it first.

With that list, the description you give the AI improves on its own: you are no longer asking for “a list of jobs”, but for a list of jobs where each foreman sees his own and the office sees them all.

Bespoke internal tools at digizone

At digizone we design and build bespoke internal tools, CRMs and ERPs so that everyone on the team works in the same place with what they need. We start with who uses the tool and what each person does with it, and from there we define roles, permissions and where the data is stored.

We saw this with DETÉN, the web application we built for Alzheimer Ávila's fieldwork in the villages of the province. It brings together each participant's record, the cognitive scales, the signed consent forms and the speech tests. Voice recordings are special-category biometric data, and the sensitive data sits in private storage with role-based access.

First, a jobs list for two foremen

Nacho did not need to give up on his board; he needed a smaller version of it. The first could be just the list of jobs for his two foremen, each seeing his own, with no client phone numbers and no keys. Once it is clear who logs in and what they see, the materials come next, then the photos and, last of all, the plumber's access to the jobs he works on. A tool that grows this way can be tried from day one without putting anything sensitive at stake.

If you would like to see how it would work for you, our free workshop, in Spanish, walks through it step by step.