Core · every plan
Automation that lives inside the permission model
An Enclessa bot is a real account that joins rooms the way a person does and is governed by the same permission model, rather than a special case that needs a second idea of who may do what. An administrator creates one in the console, mints an access token scoped to specific operations, and can revoke the token or deactivate the account at any time. Bots are not counted as billable seats, and creating a webhook or a custom command provisions one automatically.
Open betaThe platform is being built in the open, so parts of it are not there yet, behaviour changes between releases, and no availability figure is committed while it is in beta. What is still being built.
At a glance
- Nature
- A real account and a real channel member
- Created by
- An administrator, from the console
- Authentication
- A scoped access token with a mandatory expiry
- Cannot
- Reach the system console, or mint another token
- Rooms
- Managed rooms only
- Billing
- Not counted as a seat
What can a bot do?
Whatever the rooms it belongs to allow it to do, and no more. Because a bot is an account rather than an exception, there is no separate bot permission model to keep in step with the human one: give the bot a role in a channel and the ordinary resolution decides what it may post, react to or read.
- Joins channels, posts, reacts and reads exactly as its role permits
- Shows a bot badge in the room, so nobody mistakes it for a colleague
- Its messages carry a real author id, so search, audit and export treat them normally
- Creating an incoming webhook or a custom slash command provisions one for you
What can a bot never do?
Two things, both deliberate. It cannot reach the system console — a token principal is refused there in words, so even a system administrator’s own token does not administer the installation. And it cannot mint another token, which is what stops one leaked credential becoming a family of them.
- No route to platform administration, whoever the token belongs to
- No token minting, so a compromised token cannot extend itself
- No membership of an end-to-end encrypted room, because the server holds no key for one
- Deactivating the account kills its tokens at the next call
How is a bot different from a personal access token?
A personal access token acts as you: it carries your memberships, your roles and your name on every message. A bot has its own identity, so the automation is visibly the automation and does not disappear when the person who built it changes team or leaves. Both are minted the same way and both carry the same scopes.
- Anyone can mint a personal access token for themselves from account settings
- Only an administrator can create a bot and mint its tokens
- A bot survives its author leaving; a personal token does not
- Both expire, and both are stored only as a hash
What this does not do
- A bot cannot join an end-to-end encrypted room. Doing so would mean adding a visible extra member to the encryption group, and that is not built.
- A bot cannot administer the installation. There is no bot with platform-level powers, by design.
- A bot cannot create other bots or mint tokens, including its own.
- Bots reach only the operations that have been explicitly opened to token authentication. Everything else answers 401 to a token, whoever it belongs to.
- There is no bot framework, SDK or hosting. You run the code; Enclessa gives it an identity and an API to call.
Related
Bot accounts: common questions
Does Enclessa support bot accounts?
Do bot accounts count towards the number of seats we pay for?
Can a bot read our encrypted direct messages?
What happens when we deactivate a bot?
Encrypted collaboration, hosted in Europe.
Create a workspace in a couple of minutes. It is yours at your-team.enclessa.app, hosted in the European Union, with encrypted direct messages from the first one you send.
Open beta. Free plan, no payment card to start.