Step-by-step guide Claude Code for Non-Developers: internal tool from a spreadsheet →
Before anyone else gets the link to a tool you built with AI, check seven things: a login sits in front of every file, only the tool's own files are online, no passwords or keys are inside them, no real personal data is anywhere near it, odd inputs are refused, nothing is stored or sent that you didn't ask for, and you can undo it and take it down. You don't need to read code for any of them. You ask the AI to check, then you confirm the answer yourself from outside, the way a stranger would. We ran this list on a quote tool built with Claude Code on 9 November 2026, live, and this is what each check looks like in practice.
Why AI-built tools leak
The published evidence points one way. The numbers below come from security researchers and companies testing what they chose to test, so they aren't a defect rate for your tool. The pattern is what matters.
- A recorded flaw in a popular AI app builder. CVE-2025-48757, published on 30 May 2025 and scored as critical in the CVE record, describes database rules in sites generated by Lovable that let attackers read or write tables without logging in. The supplier disputes the entry, on the grounds that each customer is responsible for protecting their own application's data. The researchers who reported it scanned 1,645 projects and found the problem in 170 of them, exposing names, email addresses, phone numbers, payment details and API keys (Matt Palmer's statement, 29 May 2025).
- A scan of public apps. Escape, a security company, analysed more than 5,600 publicly available apps from AI builders and reported more than 2,000 vulnerabilities, over 400 exposed secrets and 175 cases of exposed personal data, most of them reachable without logging in (Escape, 29 October 2025).
- The models themselves. Veracode tested 18 AI models on coding tasks built around four well-known types of weakness. The average security pass rate had risen from 56% to 62%, which still leaves roughly four tasks in ten producing code with a known vulnerability (Veracode, 29 October 2026).
The dispute in the first item is the lesson. The builder's maker says protecting the data is the customer's job. If you are the customer, that means you. And the failure behind the first two items, and behind the study further down, is the same one: access control, the rule about who may reach what. The security community's standard reference, the OWASP Top 10 (2021 edition), gives the cure in seven words: "Except for public resources, deny by default." The checklist below is that sentence, applied.
The seven checks
Each check has two halves: what to ask the AI that built the tool, and how to confirm the answer without trusting it.
- A login in front of every file. A web page cannot hide what is in its files. Anyone who can open the address can read every file behind it, and in our tool one of those files holds the prices and margins. A password box inside the page protects nothing, because the files load before anyone types a password. The lock has to be part of the hosting. Confirm it: open the address in a private browser window, signed out. Then type the direct address of one file. You should see a sign-in page both times.
- Only the tool's files are online. A project folder holds far more than the tool: the copy of your spreadsheet, your notes, your test answers and a hidden history folder with every earlier version. Have the AI make a separate folder for publishing and upload only that. Confirm it: read the file list on the upload screen before you press the button. Ours showed five tool files and one settings file for the host, and nothing else.
- No secrets in any file. Ask the AI to search every file, including the save-point history, for passwords, keys and tokens. A calculator needs none. Confirm it: the answer you want is "none found". If it finds one, ask why the tool needs it, and treat that as a sign you have left the simple kind of tool behind.
- No real personal data. Not in the tool, not in the test examples, not in the project folder. Use a copy of your data with names, addresses and notes about people removed. Confirm it: open the test answers and the examples yourself and look. If the tool has to store data about customers, patients or staff, stop here. The GDPR requires security that fits the risk, including the ability to restore data and regular testing of the measures (Article 32), and no checklist like this one covers that.
- Odd inputs are refused. Ask what the tool accepts and whether anything typed into it could break it or be run as code. Our review found that entries such as 1e3 and 0x10 were quietly read as 1,000 and 16, so a slip of the finger could have produced a wrong price. Claude fixed it. Confirm it: type a negative number, letters, an absurd percentage and nothing at all.
- Nothing stored, nothing sent. Ask whether the tool saves anything in the browser, and whether any file loads something from, or sends something to, another website. When we watched ours in a browser, it made zero requests to other websites, and its hosting settings tell browsers to block any. Confirm it: a rough test is to switch off your internet connection and open the copy on your own computer. A calculator should work exactly as before.
- You can undo it and take it down. Make a save point before every upload, and find out how to delete the published version before you need to. Confirm it: after deleting, try the address. When we cleaned up our test, deleting the hosting project left its access rule and policy behind, and we had to remove those separately.
Run it every time, not once. A change to a price is also a new upload. The checks that matter most after any change are the first two: sign out, try a file's address, and read the list of what went online.
What the login looked like in our test
If everyone who needs the tool works at a computer, you may not need a web address at all. A shared team folder that only your colleagues can open does the job. Our fictional kitchen fitter quotes on a tablet at customers' homes, so we tested a private link behind Cloudflare Access, a service that puts a sign-in page in front of a website.
The set-up has three parts. A policy says who may enter; Cloudflare's policy documentation lists an Emails rule for naming individual addresses. A login method proves who is at the door; with the one-time PIN, a visitor types an email address and Cloudflare sends a code, which expires after ten minutes, only if the policy allows that address. Newly created Zero Trust organisations no longer get the PIN method automatically, so it has to be added. And the lock has to cover every address the tool answers on.
That last part is where we would have gone wrong without checking. The hosting we used offers a switch that restricts access, but Cloudflare's own documentation says it protects preview addresses only, not the main address. We added the main address by hand. Three more things from the live test:
- We uploaded an empty placeholder first. The address doesn't exist until something is uploaded, so there is a short moment before the lock is on. Our placeholder was public for about four minutes, with nothing in it.
- Claude then played the stranger. It asked for every file without logging in, including the prices file, odd spellings of the names and the insecure http address: 152 requests over two rounds. Every one landed on the sign-in page.
- One switch would have done damage. The same dashboard offers an account-wide lock. On an account that runs any other live website, it would lock that site too. Lock the one project from inside its own settings.
A login like this narrows who can reach the tool. It doesn't make the code behind it secure, and it is only as strong as the list of addresses and the mailboxes behind them. Keep the list short and look at it whenever someone leaves.
What a checklist can't tell you
An AI reviewing its own work is not an independent review. A study of 200 publicly deployed apps built with Claude Code or Lovable found at least one vulnerability in 91% of them. When the authors tried prompts written for production use, the flaws went down, and no setting removed them all (Deng, Fan and Meng, arXiv, version of 14 September 2026, a preprint that has not been peer reviewed).
The built-in tools have limits too. Claude Code has a security review command, but Anthropic's command reference says it compares your work with a remote copy of the project, the kind developers keep on a code-hosting service. In our folder, which existed only on one computer, it stopped with an error. A plain-language request to review the tool like a careful security reviewer worked instead.
So the checklist is the floor. Bring in a person who reads code when the tool stores data about people, takes payments, shows a form to the public or feeds another system. Our article on what non-developers can build with Claude Code draws that line in more detail, and the one on whether Claude Code is safe covers the other half of the risk: what the AI can touch on your own computer while you build.
The version we use ourselves
The full routine, with the security-review prompt, the publishing prompt, the route through the hosting dashboard as it looked on 9 November 2026 and a one-page check to run before every upload, is in Claude Code for Non-Developers, spreadsheet-tool edition. The launch article, How to Turn a Spreadsheet Into an Internal Tool With Claude Code, shows where the checklist sits in the whole build.
The principle fits on a sticky note: deny by default, then prove it from outside. Neurova AI builds internal tools and AI systems to healthcare standards from Eindhoven, private by default and tested against your own data. If you'd rather have someone check yours before it goes live, tell us what you need.
Frequently asked questions
Is a password box on the page enough to protect an internal tool? No. Anyone who can open the address can read every file behind the page, including the file that holds your prices or rules, without ever typing the password. The lock has to sit at the hosting level, in front of every file, so that a signed-out visitor only ever sees a sign-in page.
How do I check that strangers cannot open my tool? Open the address in a private browser window where you are not signed in. Then try the direct address of one of its files. You should get the sign-in page both times. In our test, 152 requests made without logging in, covering every file and several odd spellings, all landed on the sign-in page.
Can I trust the AI to review its own app for security? Use it, but not alone. A self-review catches real problems: ours found that an entry like 1e3 was read as 1,000. A 2026 study of 200 deployed AI-built apps still found a vulnerability in 91% of them, and better prompts reduced the flaws without removing them. Confirm the answers from outside, and have a person review anything that stores personal data.
What is the safest kind of tool to share? One that stores nothing and sends nothing: a calculator or checker that works from your own rules. There is no database to leak and no account to take over. The remaining risk is who can read the files, which a login in front of every file and a short access list deal with.
Do I need a web address at all? Not always. If everyone works at a computer, a shared team folder that only your colleagues can open is enough: they open the tool's main file from there. A private web link is worth the extra work when people need the tool on a tablet or a phone.