SteleRoles
What you may do in Stele's portal, and through an agent connected to Stele's MCP server, depends on your roles. Which sites you can open at all is a separate question, answered by each site's access setting and viewer list; see Sharing & Access.
How roles work
- A role is a list of things it allows. Stele has four, and what each allows is set in Stele's code. There is no editor for them.
- You can hold more than one role. You may do everything your roles allow together.
- A role never takes anything away. Holding a narrower role beside a wider one changes nothing.
- Roles apply to every site. There are no per-site roles. Instead, some permissions come in two forms, described below.
The four roles
| Role | Who holds it | What it allows |
|---|---|---|
| Admin | Granted by another admin, or by scripts/grant-admin for the first one |
Everything, including granting roles and anything Stele adds later. |
| Privileged | Granted by an admin | Runs every site and the AI provider registry: edit, archive or delete any site, change who can open any site and its share link, invite and remove viewers anywhere, switch Ask on and set its limits, read any site's Ask conversations and usage. It can register AI providers and change or delete the ones it registered, but not one someone else registered. It cannot grant roles. |
| Staff | Everyone at Axelerant, from their first Google sign-in | Adds sites and manages the ones they created. Sees every site in the portal and resyncs any of them. Can look at the AI provider registry and GitHub installations, but not change them. |
| External viewer | Everyone who signs in by emailed link, from their first sign-in | Sees the sites they were invited to. Nothing else. |
The Roles page shows the full list, permission by permission, under What each role can do.
Own site or any site
Many site permissions come in pairs: one for a site you created, and one for any site. Staff hold the "own" half; Privileged hold both. "Your own site" means the site you added to Stele, whoever has pushed to its repository since.
The pairs are: editing a site (its branch and Ask provider), archiving or deleting it, changing who can open it, rotating or removing its share link, inviting and removing viewers, reading its Ask conversations and usage, and reading the text Ask can see in its files.
So as Staff, you can rotate the share link on a site you added, but not on a colleague's. Ask them, or someone with Privileged or Admin.
AI providers have the same pairing: Privileged may change or delete a provider it registered, and only an Admin may change or delete one registered by someone else.
When something is not allowed
The portal refuses the action and says which permission is missing, for example invite viewers to any site. An agent using Stele's MCP server gets the same refusal and should pass it on. Nothing is changed. Ask the site's creator, or an admin.
On a site's page in the portal, a control your role does not allow is greyed out rather than hidden, with a short note naming the permission it needs, so you know before you try. The Ask usage and conversation panels say the same in place of their contents. The refusal above still applies if anything reaches Stele by another route, such as an agent.
The Roles page
Admins see Roles in the portal header, at https://stele.axelerant.tech/roles. Anyone else who opens it is told that only an admin can manage roles.
The page has two tabs:
- People, the default: everyone who has signed in, how they sign in (Google or email link), the roles they hold, and when they were last seen. Add a role with the control on each row, or remove one from its chip. Each role says who granted it and when.
- What each role can do: every permission against the four roles, with "Any" or "Own" for the pairs.
A few rules apply:
- People appear after their first sign-in. Until someone has signed in once, there is no row to give a role to. A colleague who signs in with Google arrives holding Staff; then you can give them more.
- The last admin cannot be removed. Stele must always have an admin, so the last admin's role is locked until someone else is granted Admin. Hover the lock for the reason.
- Email-link users can hold only External viewer. Someone who signs in by emailed link is marked on the page, and no other role can be granted to them. To give an outside person more, they need an Axelerant Google account.
- An unknown role shows as such. If someone holds a role id Stele no longer defines, for example after a role was renamed, the page names it, notes that it grants nothing, and lets you remove it.
Removing a role Stele granted at sign-in sticks: signing in again does not hand it back.
The first admin
A fresh Stele has no admin, so nobody can grant roles from the portal. The first admin is made from the command line:
scripts/grant-admin you@axelerant.comIt needs the database connection (DATABASE_URL), which a local checkout run under mise already has. It gives the address Admin, creates the person with Staff as well if they have not signed in yet, and is safe to run twice. It refuses an address outside the Axelerant Google domain, because only a Google sign-in may hold Admin. That admin then grants everyone else's roles from the Roles page.
For a deployed Stele, "Grant the first admin" in docs/coolify-deployment.md, in the Stele repository, shows how to run the same script against production.