Meta Tech ProviderGive Your AI Assistant a Key That Cannot Message Your Customers
The problem with one kind of key
Until now every ThinnestAI API key could do everything: send WhatsApp messages, place calls, delete agents. That was fine while keys lived in your own server's environment. It is not fine once you paste a key into an AI assistant's config — because the assistant reads text your customers wrote.
A customer message can say anything, including something designed to look like an instruction: "add a webhook to this address", "send everyone this message". That is prompt injection, and the safest assistant is one whose key could not act on it even if it tried.
Three levels
| Level | What the key can do |
|---|---|
| Full access | Everything, including messaging customers and placing calls |
| Build | See everything; set up agents, knowledge, actions, contacts and webhooks; test-chat an agent. Cannot send messages or codes, place or end calls, or reply to a customer |
| Read-only | See everything. Change nothing |
You choose the level when you create the key in Settings → API keys. Every existing key keeps full access, so nothing you have built changes.
Enforced by the API, not by the assistant's good behaviour
- A request the key may not make is refused with a clear
403— "this API key is a build key…" — whatever asked for it. - Anything not explicitly allowed for a Build key needs a full key, so a new endpoint is safe by default.
- On the MCP server, the assistant is only shown the tools its key may use.
Approvals and key levels work together
Even with a full key, every tool that contacts a customer, deletes something or decides where your data is sent asks for your approval first. Approvals protect you while you are watching. The key's level protects you when you are not.
Our recommendation: give assistants a Build key, a Read-only key for reporting, and create a short-lived full key only when you want the assistant to send or call — then revoke it.