Recording scripts you cannot upload.

Nabil BA-MOH · 29 July 2026

Most advice about recording to camera assumes the worst case is a bad take. For a lot of people it is not. The worst case is that the script left the building.

If you record internal onboarding, compliance walkthroughs, clinical explainers, case reviews, an investor update before it is public, or anything with a named client in it, then the text on your prompter is not just text. It is the thing your employer, your regulator or your NDA has opinions about. And a teleprompter is a strange piece of software in this respect: it is the one tool in the chain that holds the entire script, in plain language, before anything is even recorded.

Almost nobody asks where it goes.

Two separate leaks, not one

When people think about prompter privacy they think about the script file. That is only half of it. There are two distinct things that can leave your machine, and a tool can be clean on one and wide open on the other.

The script. Every browser-based teleprompter stores your text on a server, because that is what a browser app is. Often that is fine. Sometimes it means a document you are contractually required to keep inside your organisation is now sitting in a database in a jurisdiction you did not choose, in an account secured by whatever password you reused.

The audio. This is the one people miss. Any prompter that follows your voice has to do speech recognition somewhere. If that recognition runs in the cloud, then your microphone is streaming to a third party the entire time you rehearse and record — including the parts where you swear, restart, and say the thing you were not supposed to say out loud. The script might never be uploaded and your voice reading the script still is.

Both matter. Ask about both separately, because "we don't store your script" is a true sentence that can coexist with continuous audio streaming.

Five questions worth asking any vendor

1. Where is the script stored? On my device, on your servers, or both? If both, can I turn off the sync entirely rather than just deleting afterwards?
2. Does audio leave the device? Not "is it encrypted" — encrypted in transit still means it arrives somewhere. Does it leave at all, and if so, to whom?
3. What is retained, and for how long? Transcripts, logs, crash reports, analytics events with content in them. A vendor who has thought about this can answer immediately.
4. Does it work with the network off? This is the single most informative question, because it is binary and you can check it yourself.
5. Who are the sub-processors? If the answer is a list you can read, good. If there is no list, the tool is not ready for regulated material regardless of what the marketing says.

The airplane-mode test

Vendor answers are claims. Here is a test that turns one of them into an observation, and it takes two minutes:

1. Load a script into the tool while online, so nothing is blocked by first-run setup.
2. Turn off Wi-Fi and unplug the ethernet. Fully offline.
3. Use the tool exactly as you would for a real take: open the script, run the prompter, speak to it if it is voice-driven, advance a slide.

If everything works, the processing is happening on your machine. There is no way to fake that. If it stalls, greys out, or shows a connection error, then something in the loop was a round trip to a server — and now you know which part, because it broke exactly where the dependency is.

Do this before you put anything sensitive into a tool, not after. It is also a fair test to run on tools you already trust, and it is occasionally surprising.

The prompter is not the only leak

It would be dishonest to sell you a private prompter and let you think the job is done. The prompter is one link. The rest of the chain leaks too, usually by default:

• Your recorder. Several popular screen and camera recorders upload as they record and auto-transcribe server-side. That transcript is your script, reconstructed, in someone else's account.
• Your editor. Browser-based editors mean the raw footage is uploaded before you have decided what is in it. Including the takes where you said the client's name.
• AI features that are on by default. Auto-summaries, auto-chapters, filler-word removal, "AI titles". Each one implies content going somewhere to be processed.
• Share links. An unlisted link is not an access control. It is an unguessable URL, and it survives forwarding, screenshots and browser history.
• The dashboard thumbnail. A frame of confidential material rendered next to a filename in a SaaS interface that a support engineer can see.

Map the chain once, on paper: script tool, prompter, camera app, editor, storage, delivery. Mark each one local or remote. It usually takes fifteen minutes and it usually finds something.

Where my own tool sits

I will be direct about this, including the part that is a qualifier rather than a boast. Mirrento is a Mac application, not a web app. Your script is a file on your own disk — there is no account holding your text, nothing to sync, and no server of mine that ever receives your audio or your words. Voice tracking goes through macOS's own Speech framework on the machine, not through a recognition service I run.

The qualifier belongs right here rather than in a footnote: whether that recognition stays entirely on the machine depends on Apple's speech models for your locale being installed on that Mac. That is a property of your system, not of my code, and it is exactly why I would rather you ran the airplane-mode test than took my word for it. Cut the network, open your own script in your own language, and watch what still works — a far better use of the 7-day trial than reading any feature list, and an observation about your machine rather than a promise from me.

Two more honest caveats. Local-only is a property of a tool, not a compliance certificate for your project — your organisation's rules still apply and I cannot grant you an exemption from them. And this is a macOS application, so it is no help at all if your work happens on Windows or on a locked-down browser-only machine.

Why this is not a feature

For most people, on-device processing is a nice-to-have they will trade away for convenience. For anyone filming regulated or unannounced material, it is a gate: fail it and the tool is simply not usable, no matter how good the rest is.

That distinction is worth being clear about with yourself before you shop. If you are in the first group, pick whatever tool has the workflow you like, and spend your energy on the eight things that actually cause retakes instead. If you are in the second group, run the airplane-mode test first and let it eliminate most of the market before you evaluate anything else.