Note

An Allow-List Is Not an Admin List: What Agent Zero 2.15 Fixed in Its Chat Channels

Agent Zero 2.15 stops chat users from lifting their own tool limits. Why being allowed to message an agent must not mean being allowed to change its rules.

2026-11-02 · oss-ai, local-ai, agent-zero, agents, access-control, permissions, telegram, whatsapp, self-hosting, sovereignty, civil-liberties

Listen · 10 min · AI voice

Dark CryptoDecentral hex mesh: teal message threads converge on a wide teal hexagonal outer ring, a narrow bronze inner ring guards a bronze agent core, and a single bronze thread crosses both rings to the core; no text.

Open-source AI special · week of 2 Nov 2026

Self-hosted agents are increasingly reachable from a phone. You run the agent on your own box, wire it to a Telegram bot or a WhatsApp number, and talk to it from anywhere. That is exactly the kind of continuity this site argues for: your model, your hardware, no vendor kill switch. This week's thesis is about the part that gets skipped. Being allowed to message an agent is not the same as being allowed to change what it may do. Agent Zero v2.15, published on 1 Nov 2026 (UTC), fixes several places where that line had blurred, and the fixes are a good map of where to look in any agent you run.

What actually shipped

The v2.15 release is mostly plugin and interface work. The security section is short. In the project's own commit messages and plugin READMEs:

Telegram. "Accepted Telegram senders could use /permissions and its callbacks to persistently remove their own tool restrictions. The same access also exposed instance-wide plugin toggles." The fix adds a separate admin_users list per bot. Administrators must also pass the ordinary allowed_users check, and "an omitted or empty admin_users list grants nobody settings access."
WhatsApp. A parallel admin_numbers list now gates changes to "plugins, tool policies, profile definitions, or the browser runtime." The README adds that membership "uses the current message's normalized sender number and is refreshed on each poll; it is never inherited from the chat's previous sender."
Remote input. The input_remote tool "forwards keyboard text as terminal code, allowing a custom profile to bypass a blocked code_execution_remote capability through an independently enabled input tool." It now requires the remote terminal permission as well as its own.
Browser helper. Cross-origin windows "could read page content and invoke DOM actions through the helper's public postMessage channel." The helper now rejects foreign and opaque origins, and existing host browsers have to restart and reconnect.
Configuration scope. A project- or profile-scoped allow-list could look restrictive while the global bot kept accepting messages, so Telegram settings are now global only. Older project- or profile-scoped copies pause delivery until someone reviews them, and they are "never merged automatically."

Alongside these, v2.15 adds per-action tool permissions: a profile can allow a tool's read action while blocking its write or delete action, across the 12 bundled multi-action tools.

Two gates, not one

Every remote channel into an agent really has two questions behind it:

Who may talk to the agent? That is the allow-list: a set of user IDs or phone numbers whose messages get routed into a chat.
Who may change the agent's rules? That is administration: tool permissions, enabled plugins, profiles, where the browser runs.

Before this release, on both Telegram and WhatsApp, the second question was effectively answered by the first. Anyone on the allow-list could open the permissions menu and loosen the restrictions that were supposed to apply to them. That makes the restrictions advisory. A tool block that the restricted party can lift is a preference, not a control.

Allow-lists are often set generously, because the point of a chat channel is convenience: a partner, a colleague, a second phone, a family group. The WhatsApp README even warns that in personal-number mode "other people could misuse your Agent Zero" if allowed_numbers is left open, and that the agent "can also handle messages that other people send to that number." Once talking implies administering, every convenience decision on the outer list quietly becomes a security decision on the inner one.

The new default is the right shape: the admin list is empty, meaning nobody, and you have to name administrators on purpose. Note the direction of each empty list, though. An empty allowed_users on Telegram still means "open to all." An empty admin_users means "no one." Same shape of field, opposite meaning. Read both.

Revocation has to be live

Two smaller details in the fix carry most of the value.

First, the Telegram fix resolves membership "from the current bot configuration on each event so revocation applies to existing buttons." Inline keyboards in chat apps persist. If authorisation were checked only when a menu was drawn, someone removed from the admin list could keep pressing an old button. Checking on every callback means removal takes effect immediately.

Second, WhatsApp admin status is tied to the sender of the current message, never inherited from whoever spoke earlier in the chat. In a group, or a shared self-chat, "the last admin who spoke" and "the person sending this command" are not the same person. Binding authority to the message, not the conversation, is the general rule.

A tool block is only as strong as its siblings

The input_remote fix is a different lesson. A profile could block remote code execution and still allow a separate tool that types text into the same terminal. The capability you denied came back in through a neighbour.

The project's own profile guide says this plainly about the new per-action controls: "Tool permissions control those tool calls; they are not a filesystem sandbox. Allowing terminal execution can still let the agent read or write files even if the text editor's write action is off." Per-action permissions are useful, and finer is better than coarser. But a read-only profile only stays read-only if every allowed tool respects that, including the shell, remote input, browser, and any MCP server you attached. Our earlier note on Agent Zero's bridges maps those exits. This release closes one and documents another.

Why this matters beyond one project

The pattern isn't unique to Agent Zero. Any agent bridged to chat, whether through Telegram, WhatsApp, Matrix, Signal, or a Nostr DM bot, faces the same split. Chat platforms authenticate accounts, not intentions. Phone numbers get recycled and SIMs get swapped. Bot tokens leak. People share a device with family, especially where one phone serves a household. For activists, journalists, and small organisations running their own tools so they aren't dependent on a platform that can be switched off, a compromised chat account is a realistic threat. It shouldn't also be a way to rewrite the agent's rules.

The healthy design is the one v2.15 moves toward. Talking happens over the convenient channel. Rule changes happen through a narrower path: a named admin list, checked live, bound to the current sender, and with permission changes for the most dangerous capability, host Computer Use, kept off the chat channel entirely. The Telegram README states that "Computer Use permissions stay with A0 Launcher/CLI."

What an operator can check

If you run Agent Zero with a chat channel, the release notes and READMEs point to concrete checks:

Read both lists. Confirm allowed_users or allowed_numbers isn't empty unless you truly mean "anyone." Confirm the admin list names only you, or is empty.
Review paused scoped configs. If Telegram delivery paused after the upgrade, use "Show existing configurations" and re-apply access rules globally before deleting old copies, as the README describes.
Restart host browsers after upgrading, so the v2 helper replaces old listeners.
Audit read-only profiles as a set. Look at every allowed tool together, not one switch at a time. If terminal execution is allowed, the agent can still read and write files, whatever the text editor's switches say.

Elsewhere in local AI

Ollama shipped v0.40.8 through v0.40.13 between 21 and 28 Oct 2026. Highlights were Liquid AI's small LFM3 family (a 1.7B text model with a stated 256K context, plus vision, audio and "omni" variants), speech generation on macOS through an OpenAI-compatible /v1/audio/speech endpoint, and Recursive's Flint coding model, published under Apache 2.0. LFM3 support reached Linux and Windows in v0.40.13. Small models on modest hardware help continuity, but check what each model card's licence actually allows. Read our note on open weights versus open source before you depend on one.

What this is not

This note doesn't rank Agent Zero against other agent frameworks, and it doesn't claim the fixed issues were exploited in the wild. The commits describe the weaknesses and the fixes; we report those and nothing more. It isn't a setup guide for Telegram or WhatsApp bots, and it doesn't recommend bridging an agent to any chat platform at all. It's also not a claim that per-action permissions make an agent safe. The project itself says they are not a filesystem sandbox. Nothing here is investment, token, custody, swap, or trading advice, and nothing recommends buying any product or service.

Frame: Messaging is a door. Reconfiguring is the key to the locks. An agent you control should never hand over the key just because someone came through the door.