

2026-05-23
by Uri Walevski
When building non-isolated personal assistant bots (isolateUsers = false), you often want your assistant to have maximum capability. Under the hood, this means giving it tools to provision real cloud VMs, manage OAuth tokens, and execute code that reads and writes your secrets.
But if other people—such as team members, group chat participants, or external contacts messaging your bot via connected WhatsApp (Supergreen) numbers/accounts—are interacting with your assistant, a critical security issue arises. Because isolateUsers = false is active, there are no independent user sandboxes. All participants share the same session context, and anyone who can reach your bot's Supergreen number or mention it in a shared group can potentially prompt-inject the assistant. A clever instruction or a malicious user could convince the assistant to perform sensitive operations like spinning up heavy cloud VMs, exposing your OAuth tokens, or reading API keys on their behalf.
Today, we're introducing Secure Administrator Approvals to elegantly solve this security surface.
Useful assistants need real power. If your assistant can deploy code, check production logs, or integrate with Google Drive, it needs credentials and execution environments.
In personal assistant bots, users are not isolated. This is by design: you want your assistant to coordinate tasks across multiple users or be available to a shared group. However, when the assistant is connected to public channels like a WhatsApp Business or Supergreen account, any contact or group participant can send a message. Since there is no user isolation, a non-admin user talking to the bot in a group chat could potentially trick the bot into using these administrative tools. Keeping the bot useful to you while ensuring it doesn't leak power to others is a difficult tension.
From now on, we automatically intercept sensitive tool calls if the bot is non-isolated (isolateUsers = false) and the current conversation is not with one of the bot's configured administrators:
create_vm), initiate/refresh an OAuth flow (create_oauth_callback, refresh_oauth_token), or run a Safescript program that maps encrypted secrets (run_safescript), the tool immediately pauses and returns:
"requesting admin permission for this action, once admins approve you'll get notified"[System notification: The administrator has approved your request to execute <toolName> (Request ID: <requestId>). You can now re-call the tool and include this request_id.]
This automatically wakes the agent up and triggers a safe re-run where it can proceed using the single-use request_id.If you are a guest developer just trying out prompt2bot, or if you haven't set up your administrator email or phone yet, you won't be locked out.
The system automatically detects if the bot lacks any contactable admins (no registered phone or email). If so, it bypasses the approval flow so your development, testing, and iteration remain completely instant and friction-free.
By wrapping the exact execution boundaries—VM creation, OAuth initiation, and static Safescript secret mapping—we've secured the entire assistant capability layer with zero code duplication. Your credentials and cloud compute remain fully locked down, allowing you to safely share your personal assistants with group chats and external users without fear of abuse!
← All posts