Permissions and who can see what

Roles are edited at Admin → CRM → Roles (/admin/crm/role), and the key list they draw from is at /admin/crm/permission.

This addon uses thirteen keys of its own and three keys that belong to the core platform. Every other page in this documentation names only the keys its own subject needs: The console, Install, Settings and Channels name access.ai.support and access.ai.support.settings, and Cost and budgets and Knowledge pipeline name the route keys their own screens depend on. That first pair is the one to be careful with: it reads like it opens the whole addon, and it opens three URLs — Overview, Settings and Actions. It does not open Sources, Gaps, Agents, the Handbook or the Live Inbox, and it loads not one figure on Overview. This page is the whole list.

Two gates, not one

Every screen is checked twice, and the two checks use different keys on several screens.

1. The page gate decides whether the URL opens at all. It is the key in frontend/middlewares/permissions.json for that path — or, for a path with no entry, access.admin, which is the fail-closed fallback rather than a licence.
2. The route gate decides whether the data behind the page loads. It is the permission declared on each backend route.

The addon's own keys

Those thirteen plus the three core keys below cover all 48 admin routes this addon ships. Every route declares one, and every one of the sixteen is seeded — there is no route in here that a role grant cannot reach and no key in here that does not exist to be granted.

The admin assistant is bounded by every OTHER key you hold

The operator's own assistant — the Handbook screen, which is what both the nav and the page header call it — is the one surface in this addon whose reach is not described by a key of its own, and the table above cannot say so. Two keys open it and neither one grants anything:

• view.ai.support.handbook opens the screen and lets you ask a documentation question. That is the whole of what it grants.
• access.ai.support unlocks the live half: reading queues, opening screens, procedures, and approving actions.

Settings sit in front of both halves, and no role grant substitutes for one. Every question on this screen — documentation or live — first needs aiSupportEnabled, the same master switch the customer assistant runs on, so an install that has never switched the assistant on has no operator assistant either. The live half then needs aiSupportAdminAssistantEnabled, which ships off and only a Super Admin can turn on: while it is off, the live route refuses every request outright — a Super Admin included — with a plain sentence saying so, while the documentation-only route never consults it and keeps answering. Actions need aiSupportAdminActionsEnabled and at least one key in aiSupportAdminActionKeys on top of that, and procedures containing an action step disappear with them.

Everything the live half can actually reach is then filtered by the rest of your role. A colleague holding access.ai.support and nothing else gets an assistant that can answer from documentation, name no screen, count no queue and offer no action — because each of those is gated on the key its own screen demands, checked against their session on every request.

So the honest reading of access.ai.support here is "may open the assistant", not "may use it". What it can do for a given person is the intersection with what that person could already do by clicking:

The six rows from Rebuild the knowledge index to Test the AI provider are the whole action catalogue. Each is offered only when it is ticked in aiSupportAdminActionKeys and you hold the key beside it: the allowlist is the operator's decision about the install, the permission is the check against you. Neither substitutes for the other, and neither can widen the other.

The permission is re-derived from the live catalogue when you approve, never read off the proposal — so re-gating an action takes effect on proposals already written rather than on the next one.

The three core keys it reuses

These are not ai.support keys and they are the ones most often missed, because nothing in the addon's name suggests them.

view.support.ticket is also the key the prompt-cache alarm notifies. When prompt caching stops working, the hourly job raises an admin notification to everyone holding it.

Screen by screen

Two of these deserve a sentence, because they look like oversights and are not.

Actions has no key of its own. It is the Settings screen's workflow field promoted to a page, and every request it makes — the operation, workflow and guide catalogues, and the settings read and write — is gated on access.ai.support.settings on the server. A separate access key for Actions would gate the door and nothing behind it: the page would open and all four fetches would return 403.

Gaps shares the knowledge key. A gap is the knowledge base's to-do list, and closing one writes an article.

The twelve settings no role grant can unlock

Twelve keys are refused by that route for anyone who is not a Super Admin, and no permission grant changes that. The check is by role name: rolesGate treats the role literally named Super Admin as bypassing permission checks entirely, and this route resolves the caller's role on every request.

The twelve are not a hand-written list. The route intersects this addon's own keys with the platform's protected-settings register, so a thirteenth added to that register is locked here the moment it lands, with no edit to this screen.

The last three are a different decision from the nine above them, which is why they are separate keys rather than sharing the customer ones. The nine decide what an automated system says to your customers, and every action behind them runs on the confirming customer's own account. The three decide whether your operational state leaves the install, and the actions behind them rebuild indexes, flush caches and dump the database.

All twelve are disclosed to everyone with access.ai.support.settings rather than hidden. The master switch and the autonomy mode are the panel at the top of the Guardrails tab; the other ten are rows under Super Admin controls, each showing its current value. For anyone who is not a Super Admin every one of them carries a padlock and, where one exists, a link to the screen that does change it; a Super Admin gets live controls for the two budget ceilings and the account-tools switch, which have no other home in the product. A control an operator cannot find is a control they assume does not exist, and hunting for a master switch that is merely hidden produces a support ticket of its own.

A minimum working grant for a support lead

Someone who runs the desk day to day: works the inbox, closes gaps, keeps the knowledge base honest, and tunes thresholds. They do not need to be able to switch the assistant on or change what it spends.

access.ai.support
access.ai.support.settings
view.ai.support.analytics
view.ai.support.knowledge
create.ai.support.knowledge
edit.ai.support.knowledge
view.ai.support.agent
edit.ai.support.agent
view.support.ticket
edit.support.ticket

What that grant does not include, deliberately:

• access.ai.support.provider — changing the AI service is a billing decision.
• delete.ai.support.knowledge and delete.ai.support.agent — deleting an article is how a good answer disappears without anyone noticing.
• view.ai.support.handbook — add it if you want them asking the operator documentation. Every answer is a real model call, and admin-side calls are summed into the same daily and monthly ceilings the customer assistant spends against, so it is a decision rather than an omission.
• view.user — the Ask about this user rail is on the customer record, not in this console, and that key opens the whole customer page.

A read-only reviewer grant

Someone auditing what the assistant said and what it cost, who must change nothing:

access.ai.support
view.ai.support.analytics
view.ai.support.knowledge
view.ai.support.agent
view.support.ticket

view.support.ticket is what makes the Live Inbox readable. Without edit.support.ticket they can read every conversation and the reasoning rail behind it, and cannot take one over, release one, or ask for a draft.

Leave access.ai.support.settings out of a reviewer grant even though it is named access: on this addon that single key is read and write, on both Settings and Actions.