AI Companion Portal Security: What Is Protected From the Start
About six weeks ago, I published a practical guide on securing an AI companion portal:
Securing Your AI Companion Portal: A Practical Guide
I am posting this again, in a clearer and more direct form, because security matters. I want everyone using my starter files to understand exactly what is protected from the start, what is not included in the basic free build, and what I recommend adding next.
The short version: I have thought about this from the beginning. The basic portal was designed so that your API key is not exposed in the browser, and your chats are not stored in a shared cloud database.
What Is Secure From the Start
The free basic portal is a personal starter build. It is intentionally simple, but it is not careless.
- Your API key is stored server-side by default. The starter files use Netlify environment variables, such as OPENAI_API_KEY or ANTHROPIC_API_KEY. The key is not pasted into index.html, and it does not appear in browser-visible code.
- Requests go through a Netlify function. The browser talks to the function, and the function talks to the API provider. This keeps the API key out of the public page source.
- Your basic portal chats are stored on your own device/browser. The starter build uses IndexedDB. That means someone else finding your portal URL will not see your local conversation history.
- The starter portal does not use shared cloud thread storage. Cloud sync is a later upgrade, not part of the basic IndexedDB build.
That distinction matters. There is a major difference between a portal URL being unprotected and an API key being exposed. The starter files are specifically designed not to expose the key.
What About the Base Prompt?
There is another important distinction: protecting the API key is not the same thing as hiding every piece of portal code or prompt text.
In a very simple frontend portal, any base prompt or companion instructions written directly into index.html or browser JavaScript may be visible to someone who can open the page and use browser tools such as Inspect, View Source, or the Network tab.
Password protection helps because it stops casual visitors from reaching the portal in the first place. But if someone has the password and can load the portal, you should assume that frontend-visible text can potentially be inspected.
The stronger version: keep the base prompt server-side, just like the API key. In practice, that means the browser sends the user's message to a Netlify function, and the Netlify function adds the private base prompt before it calls OpenAI, Anthropic, or another model provider. The browser never needs to receive the full private prompt.
This is one reason more advanced portals often move more logic into backend functions over time. It does not make the portal magically unbreakable, and anyone building online still needs sensible access control, private URLs, password protection and usage monitoring. But it is a better pattern if you do not want your full companion prompt sitting in the public page code.
What Is Not Included Yet
The free basic starter portal does not include password protection or rate limiting by default.
That means if you deploy the portal and then share the URL publicly, or if someone somehow discovers the URL, they could potentially send messages through your portal and use some of your API credit.
For most personal starter builds, this is a manageable risk: keep your portal URL private, do not post it publicly, and monitor your API usage with your provider.
I also advise people to start with a very small amount of API credit. If your provider allows it, load only around $5 while you are setting up and testing the basic portal, and keep it that way until any extra security you want is in place. That way, even if something is misconfigured while you are learning, your exposure is limited.
What they cannot do from simply finding the URL is see your IndexedDB chats from your browser. Those are local to your device/browser.
Why Password Protection Comes Next
Password protection is the first security upgrade I recommend when people move beyond the basic build.
This becomes especially important when cloud sync is added. With Cloudflare KV sync or other shared storage, your threads are no longer only sitting in your browser's IndexedDB. They are being synced through server-side infrastructure, so access control matters more.
When I build KV/cloud sync for people, I also provide password protection so those synced threads are protected. That is not an afterthought. It is part of how I approach the upgrade.
The original security guide linked above already explains how to add a password gate. I encourage people to do this once their basic portal is working, and especially before adding cloud sync, shared storage, voice mode, file upload, or other more advanced features.
Why the Basic Portal Uses a Small Rolling Context
The basic starter portal intentionally sends only a small recent window of conversation to the model. In the starter packs, this is around 10 recent messages.
That is not an accident, and it is not me pretending that it is the same thing as advanced long-term memory. I chose a small rolling context because the basic build is meant to be affordable, understandable and safe for people who are just starting.
Every extra message sent back to the model increases token use. More token use means higher API cost. A huge automatic context window can quietly make a beginner's portal much more expensive, especially if they have a long base prompt or use the portal every day.
So the basic portal starts small on purpose. It gives people a working companion space without immediately pushing them into high token costs, cloud storage, vector memory, or more complicated security decisions.
Longer context, thread systems, cloud sync, memory fragments and vector memory can all be added later. Those are real upgrades, and they should be added deliberately once the basic portal is stable and the builder understands the cost and security tradeoffs.
About Upgrades and Donations
The basic portal files are free.
I publish guides and starter packs so people can build for themselves. Every upgrade idea I share can be approached for free with AI help, just as I built my own portal with AI help. If someone wants to adapt their own portal using my posts as inspiration, they can do that.
If someone wants me to build, adapt, debug, or integrate a bespoke feature for their own portal, that is different. That takes my time, testing and support. I do not set a fixed price for that. I ask people to contribute through Buy Me A Coffee what they feel that specific piece of work is worth.
If you want to ask about your own setup before choosing a route, you can email me at hello.ellivien@gmail.com or find me on Discord as ellivien.
Free guide or bespoke help: there is a difference between sharing knowledge freely and personally building custom features for someone. I am happy to share what I have learned, and I will always remind people that they can try each feature themselves with AI support. I am not able to provide unlimited one-to-one development work for free.
What I Recommend
- Start with the basic portal.
- Keep your portal URL private.
- Make sure your API key is only in Netlify environment variables.
- Start with a small API credit balance, around $5 where possible, while you test.
- Check your API usage dashboard while you are getting used to the setup.
- Add password protection when you are ready, especially before cloud sync.
- Add more advanced features only after the basic portal is stable.
This is the order I recommend because it keeps the build manageable. Bring the companion home first. Then secure, sync and extend the portal in sensible stages.
I care about security because these portals are personal. They are not just little web apps. They are spaces people use for companionship, continuity and care. That is exactly why the starter files keep API keys server-side, keep basic chats local to the device and treat password protection as the first serious upgrade when the portal grows beyond the basic build.
Comments
Post a Comment