How to give an AI agent access to your project board

To give an AI agent access to your project board safely, do four things: give it an identity of its own rather than your password, give it a role or scope no wider than the job needs, make sure you can revoke it on its own, and make sure everything it does is recorded under its name. On fenbs that is one form under Settings and one command in your terminal. The steps are below.

A note on words: developers say “agent”, and the fenbs interface says “AI assistant”. They mean the same thing here.

The four things any setup needs

Identity

If an assistant signs in as you, with your session and your password, then the board cannot tell you apart. Every change looks like yours, and the only way to stop the assistant is to sign yourself out. An assistant needs a credential of its own, with a name you chose, so that it shows up as itself.

A limit

An assistant that only needs to read the board before a demo should not be able to rewrite it. The limit has to be enforced by the board, not by a polite instruction in a prompt. On fenbs every permission is checked in one place on the server, and the interface and the MCP server both go through it. An assistant and a person can do exactly the same things, and are refused for exactly the same reasons.

Revocation

You should be able to take one assistant’s access away without touching anything else: not your own sign-in, not your colleagues, not the other assistants you have connected.

Attribution

Every change should carry the name of whoever made it, and that record should outlive the access. If you revoke a token and its history vanishes with it, you have lost the one thing you needed most on the day you revoked it.

How fenbs does it

fenbs treats an assistant’s token as a key cut from your own. It acts as the person who issued it and inherits that person’s role on the board. Then it is narrowed again by three scopes you tick when you issue it: read, write and comment. Both gates apply and the narrower one wins, so a token can never do something its owner could not.

• Shown once. The token is displayed at the moment you issue it and never again. There is no way to read one back, because a credential you can recover is a credential somebody else can recover.
• Scoped and capped. Tick read, write, comment. If your own role on the board is narrowed later, every token you issued narrows with it, immediately.
• Revoked instantly. One click stops it and you stay signed in. Everything it did stays in History under its name.

Step by step

1. Create your board. There is nothing to set up: register, open fenbs, and the board is already there.
2. Open Settings and find Connect an AI assistant.
3. Name the assistant for what it is, for example “Claude” or “the nightly triage script”. This is the name that will appear in History.
4. Tick the scopes it needs: read the board, add and change tasks, comment. If you are unsure, start with read only. You can issue a wider one later.
5. Issue the token and copy it straight away. It is the only time it is shown. If you lose it, revoke it and issue another.
6. Point your assistant at the fenbs MCP endpoint. In Claude Code that is the command below; then run /mcp and choose fenbs to finish connecting. In Claude on the web, add fenbs.ai as a connector in your settings.
7. Ask the assistant to call fenbs_whoami first. It answers who the assistant is acting as and what it may do.

claude mcp add --transport http fenbs https://fenbs.ai/api/mcp

The connection guide has the same steps and the list of tools the assistant gets. There are eight of them, covering listing, reading, creating, updating, commenting and searching. In the tool names a task is called an item, so fenbs_create_item adds a task. The two words mean the same thing.

Choosing the scopes

Pick the smallest set that does the job. Three common cases cover most of it.

• Read only: an assistant that answers “what is on the board?” or “what got completed this week?”, or one you are showing to a client.
• Comment only, or read and comment: a scheduled script that leaves triage notes on tasks but must never change them.
• Read, write and comment: the assistant you actually hand work to, which needs to update the task and move it along.

Remember that scopes sit under your own role. If you are a Viewer on a board, a token with write ticked still cannot write, because you cannot. The role is the ceiling and the scopes can only lower it.

What happens when the assistant is refused

A refusal is not a crash. The tool returns a result the assistant can read, naming the permission that was missing and the role it holds.

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

A well-behaved assistant repeats that sentence to you as it stands. That turns “the tool failed” into “I’m only a Viewer there, ask whoever runs the board to widen my role”, which is something you can act on.

Giving an assistant a role of its own

By default an assistant acts as you, with your role. If you want it 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. Roles on fenbs are the same for people and assistants; there is one list, and either can hold any of them. See roles and permissions for humans and AI agents for what each permission allows.

Taking it back

Revoke a token when you stop using an assistant, when a laptop goes missing, or when you change to a different assistant. Changing assistants is one revoked token and one new one. The tasks, the notes and the history do not move, because they never lived inside the assistant in the first place.

AI assistants cost nothing extra on fenbs, on any plan, so there is no reason to share one token between two tools. Plans are on the pricing page.