Embeddable AI Widget: API Key Security Done Right (Simply Explained)

I built a small piece of software that lets my customers add an AI assistant to their own websites with one line of code. They copy it, paste it into their site, and the assistant shows up. Lead capture, voice conversations, all of it.

That's the dream for any software company. Your product spreads across hundreds of customer websites without you doing a thing.

Then I sat down to actually build it and ran straight into the problem most people get wrong. Security.

Why this is harder than it looks

Here's the thing nobody warns you about. The moment your software runs on someone else's website, you lose control of it.

Think of it like handing a customer the master key to your entire building, just so they can unlock one room. Once that key is out in the world, anyone can copy it.

In software terms, every website's code is visible to anyone who knows where to look. It takes about three clicks. So if I put my real "master key" (the thing that lets my AI do its work) into that code, anyone could grab it.

And once someone has it, they can run up my bill, abuse my AI, and stick me with the cost.

It gets worse if I use one master key for all my customers. One leak wouldn't expose one customer. It would expose every customer at once. That's a fire I do not want to fight.

So I had three problems stacked on top of each other:

• The real master key can never reach a customer's website.
• Each customer needs their own access, not a shared one.
• I need to shut off any customer's access instantly if something goes wrong.

The coat check solution

Here's how I solved it.

Instead of giving each customer my master key, I give them something more like a coat check tag. On its own, the tag is worthless. It can't open the building. It can't touch another customer's stuff. All it does is prove which coat is theirs.

When a customer's website loads my assistant, it shows this tag to my server. My server checks it, then hands back a temporary pass that expires in a few minutes. The assistant uses that short-lived pass to do its job. When the pass expires, it just asks for a fresh one.

The real master key never leaves my building. Ever. The website only ever holds something that's useless the moment it expires and only works for that one customer.

This matters for a reason that lets me sleep at night. If a customer cancels, or if I think their tag got stolen, I flip one switch and their access stops everywhere on the next request. No delay. No scramble. One change.

Compare that to the shared-key approach. To shut off one leak, you'd have to change the master key and hand a new one to every single customer at the same time. That's a coordinated nightmare. My way, it's flipping one switch.

Keeping the front door dumb on purpose

The little piece of code my customers paste into their site is intentionally simple. It holds no secrets. It does nothing valuable on its own.

Its only job is: read the coat check tag, ask my server for a temporary pass, and load the assistant.

I also load the assistant inside a sealed box on the customer's page. This does two useful things at once. It stops the customer's website design from breaking my assistant, and it stops the customer's website from snooping on my assistant's insides. Good fences make good neighbors, especially when your software is a guest on someone else's site.

If someone downloads my code and pulls it apart, they learn nothing. There's no secret in there to steal because I never put one there.

One bonus: because the code is so simple, I can update and improve it whenever I want, and every customer gets the better version automatically. The line they pasted six months ago keeps getting the latest secure build. They never touch it again.

Making sure one customer can never see another's data

This is the part I obsess over. When a customer's leads and conversations flow back to me, they have to land in the right place. Customer A should never, ever see Customer B's information.

Here's the key decision. When a request comes in, I figure out which customer it belongs to based on that secure temporary pass I handed out, not based on anything the website claims about itself. Websites can lie. The secure pass can't.

This kills off an entire category of mistake. If I trusted the website to tell me "I'm Customer A," a clever person could just change that to "I'm Customer B" and read someone else's data. By deciding it on my end, that trick is impossible.

And because I don't trust even my own code to be flawless, I add a second wall at the database itself. Even if I made a mistake in my main code, the database would still refuse to hand over another customer's data. Two separate walls have to both fail before anyone sees anything they shouldn't. That redundancy is the difference between a small bug and a real breach.

The checklist I run before any customer touches this

Before this software goes anywhere near a paying customer, I check six things:

• The real master key never appears on a customer's website. Anywhere.
• Each customer has their own access, limited to a few specific actions, and I can shut it off with one switch.
• The temporary passes expire in minutes and only work for one customer.
• I limit how fast passes can be requested, so a stolen tag can't be used to flood the system.
• The assistant loads in a sealed box, separate from the customer's site.
• Every piece of data is tied to the right customer by the secure pass, with the database itself as a backstop.

If all six are true, I can hand it to real customers. If even one is false, it's not a product. It's a demo wearing a costume.

I'll be honest about what this does not fix. A customer can still overuse their own assistant and run up their own usage. That's a known, manageable problem, and I can charge for it. What I can't afford is one leak exposing everyone. This pattern stops that.

This is the difference between software that looks good in a demo and software you can actually let loose on a thousand websites you don't control.

Ready to bring AI leadership into your company?

I work with a small number of companies at a time. If you're serious about AI, apply to work together and I'll review your application personally.

Apply to Work Together