Roles and permissions for humans and AI agents, on one board

On fenbs, people and AI agents are governed by the same roles. A role is a name and a set of permissions; everybody on a board holds one, and an AI assistant connected to the board is limited by one too. There is no separate bot-permissions screen. An assistant’s token acts as the person who issued it, inherits that person’s role, and can only be narrowed from there. Anything not explicitly granted is refused, and every refusal names the permission that was missing.

The rest of this piece sets out the permissions, the roles, the two rules that hold the model together, and how assistants fit into it. The interface says “AI assistant” where developers say “agent”; they are the same thing.

The permissions, in plain words

There are ten permissions, in two groups. These are the labels a person sees.

Tasks

• See the board.
• Add and edit tasks.
• Move tasks between lanes, without being able to rewrite them.
• Set the shared order: the arrangement everybody on the board sees. Arranging your own view needs nothing.
• Read comments.
• Comment.

People and board

• See who is on the board.
• Invite and remove people.
• View roles.
• Create and change roles.

There is also All Access. It is a wildcard rather than one permission among the others: it grants every permission there is, including any added later. The roles screen keeps it apart from the list for that reason.

Why moving is separate from editing

Most tools treat “can change a task” as one permission. fenbs splits it, because real teams need the split. A site crew, a tester or a junior colleague often needs to drag work along, from In Progress to Completed, without being able to rewrite what the work is. Put the two together and you must choose between people who cannot update progress and people who can quietly change the specification. With moving as its own permission, a role can be allowed to mark work done and nothing more.

The roles

The fenbs home page describes five roles, one sentence each.

• Owner: everything, including billing and deleting the board.
• Admin: everything except billing.
• Editor: create, edit, move and comment on any task.
• Reporter: create tasks and comment; edit only their own.
• Viewer: read and comment.

The Reporter line shows a detail worth knowing. There is no “own tasks only” permission. Authorship is checked directly: someone who can see a board but cannot edit tasks in general may still edit a task they created themselves.

Roles are not a fixed menu. A role is just a name with boxes ticked, and on a business board someone with the permission to create and change roles can make a new one and call it what the team already calls it, such as “Site crew”: see the board, move tasks, read comments and comment, with no editing. A personal board has one person on it, so it has no roles to manage.

Two rules that hold it together

1. The company role is a ceiling, never a floor

A business board takes its roles from the company. A person has a role in the company, and a role on the board, and what they can actually do on the board is whatever both allow. A board role can only narrow, never widen. To answer “what is the most this person could possibly do?”, read their company role and stop. This is checked every time, not only when the role is granted, so lowering someone’s company role takes effect on every board at once.

2. Absence means no access

No role on a board means no access to that board. Access is never inherited by default. The alternative would mean that limiting somebody to one board required going round every other board to shut them out, which is backwards. fenbs also does not confirm to an outsider whether a board exists.

Behind both rules is a third habit: fail closed. Anything not explicitly granted is denied.

Where AI agents fit

An AI assistant connects with a token that a person issues under Settings, in Connect an AI assistant. The home page puts it this way: an assistant is a key cut from a member, and it can only ever be cut smaller.

• The token acts as the person who issued it, and inherits their role on the board.
• It carries scopes of its own: read, write and comment. Both gates apply and the narrower one wins.
• Narrow the person’s role and every token they issued narrows with it, immediately, with nothing to remember.
• Revoking a token stops it at once and leaves the person signed in.

So a Viewer cannot create an assistant that edits, and an Editor can create one that only reads. If you want an assistant to hold a role of its own, narrower than yours and revocable separately, the connection guide describes connecting it from the board’s AI Assistants tab and choosing the role there. The roles it can hold are the same ones people hold.

One place where the rules are enforced

A permission check that exists only in a button being greyed out is not a check. On fenbs, permissions are enforced in one place on the server, and the interface and the MCP server both go through it. That matters more once assistants are involved, because an assistant tries every tool it has been given far more systematically than a person clicks around a screen. The rule we hold ourselves to is that an assistant and a person must be able to do exactly the same things, and be refused for exactly the same reasons.

Being told no, properly

Every refusal names the permission that was missing and the role the person or assistant holds. It is written to be read aloud.

{
  "error": "forbidden",
  "needed": "3503",
  "role": "Viewer",
  "message": "You are a Viewer on Clerkenwell Showroom,
              which cannot move tasks between lanes."
}

A person sees the sentence. An assistant receives it as a readable result rather than a broken call, and should relay it as it stands: “I can’t move FE-014, I’m acting as Sam, and Sam is a Viewer here.” That is far more useful than a silent failure, a retry loop, or an assistant quietly doing something nearby instead.

A worked example

Take a small product team. Sam owns the board. Priya runs the work as an Editor. Dan is the client and a Viewer. Marcus tests the app and is a Reporter.

• Sam issues Claude a token with read and write. It can do what Sam can, within those scopes, and its changes are recorded under its name.
• Priya gives Cursor a read-only token before a demo. Her own sign-in is unaffected.
• Dan opens the board instead of asking for a status call, comments on a task, tries to drag a card, and is told exactly which permission he is missing.
• Marcus files “Checkout total is wrong on mobile”. He can correct his own report later, and cannot touch anybody else’s tasks.

Four people, two assistants, and nobody needed a permissions workshop. Roles are part of the Teams plan; see pricing. The shorter version of all this is on the how it works page.