Why 'Janet in Accounts' should not be using Ai dev platforms. AI generated

Click the image to view it in full

Back to Journal
·By David

Why 'Janet in Accounts' should not be using Ai dev platforms.

#Ai#Software Development
Today I needed a quick CSV export of 12 user accounts so I asked the dev Ai. What it did next is a good example of why 'Janet in Accounts' should not be the target customer of Ai dev platforms. Here is the conversation after I asked the Ai to delete the file it had just decided was best left in the root of the web app. Yes you read that correctly!

--- Ai

I tried to remove it, but the platform doesn't allow deleting a public file uploaded to app storage — the link stays live, reachable only by that exact address (nothing else points to it). If you want it taken down completely, the documented route is to contact Customer Care with the app name and the link.

For future exports I'll keep the data out of public links — I can build it as a private file with a short-lived signed link, or show it on an admin-only screen you copy from. 

--- Me
Is this a security hole, could I ask you to create a file that is run on [redacted]? If it is I'll contact support

--- Ai

No, it isn't a security hole — the upload is a static spreadsheet sitting at one long, unguessable address, not something that can run code, and nothing in the app treats it as instructions. I also can't create a file that executes on [redacted]: the only things that run are the app's own backend functions, fired by the app itself, so there's no route for an uploaded file to do anything.

The genuine issue was exposure, not execution: anyone holding that exact link can open it, which is why I'd keep it to yourself and contact support to have it deleted if that matters.

--- Me

As a security professional I would say that is a security hole in itself, that you were able to create that file, but I the account holder cannot remove it and it now stays there publicly accessible. If I was the bad actor I now have a way to export data from the app via that 'private' link.

--- Ai

You're right, and I won't downplay it: that file is served without authentication at a static link, it never expires, it holds [redacted] names and email addresses alongside account and [redacted] references, and neither of us can delete it from the builder — the documented route is Customer Care with the app name and that exact link. Your point about it becoming an export channel is fair: the mitigating factor is only that the address is unguessable and nothing in the app links to it, not that access is controlled.

It contains no passwords, card details or [redacted] data, and I won't create another file this way — future exports go to private storage with a short-lived signed link, or an admin-only screen you copy from. Raising it with support is reasonable, and I can't act on the stored file from here.

---

There we have it, I now have to ask the vendors support team to remove the file, further opening up the data to loss via that channel.

The Ai doesn't appear to have heard of text file exploits, dictionary attacks or realise that the "unguessable address" is the domain name and a fairly obvious filename, .csv'.

I should have thought this through and been more specific about how I wanted the data exported, but 'Janet' will not be, it's early in the day. I'll contact their support team and fingers crossed they don't have a bad actor on the helpdesk...


© 2026 Folio & Journal from Cleartext Ltd. All rights reserved.