How to keep an AI agent from wrecking your task board
An agent does exactly what its tools allow, as often as its goal seems to need. Three controls — a role, scopes, and a signed history — turn that from a risk into a colleague.
6 min read
The stories are all the same shape. Somebody connected an agent to a real system with a key that could do anything, gave it a goal, and came back to find it had done something they would never have done — closed forty tickets, renamed a column, deleted the duplicates that were not duplicates. The agent was not malicious. It was thorough. Thoroughness with an all-access key is the problem, and the fix is not a smarter agent; it is a smaller key.
Why an agent is not a person with a login
A person reads the screen and hesitates. An agent reads a tool result and continues. It will call a tool a hundred times if its goal seems to need it, and it cannot tell “this is what they meant” from “this is what they said”. So the controls you rely on for people — good judgement, a pause before the destructive click — do not exist. What you have instead is what the tool itself allows, and that has to be set on purpose.
Control one: a role, and it can only narrow
On a fenbs board an agent holds a role: the role of the person who approved it. A role is a short list in plain words — see the board, add and edit tasks, move tasks between lanes, comment, see people, manage people, change roles — and a board role can only narrow what the person’s team role allows, never widen it. So the first question is not “what should the agent be able to do?” but “what can I do, and how much of that should it get?”. If you would not let a new hire delete tasks in their first week, do not let the agent.
Control two: scopes, ticked when you approve
When an agent connects over MCP, fenbs opens in your browser and asks what it may do: read, write, comment. Three ticks. A token with read only can list, search, summarise and answer questions and cannot change a thing. That is the right first week for any agent. Both gates apply — role and scopes — and the narrower one wins, so a write scope does not help an agent whose owner cannot write.
Control three: a history that names it
Every change an agent makes is recorded as “Claude via Sam Ade” (or Cursor, or ChatGPT), with the task, the change, and the time. This is what makes the other two controls usable: you can start narrow, read what the agent would have done, and widen when it has earned it. It is also what makes a mistake recoverable: a move is recorded with its from and to lanes, and moving it back is one click that is recorded too.
What fenbs does that you cannot switch off
- Fail closed. Anything not explicitly allowed is refused, for agents and people alike.
- Refusals in sentences. “You are a Viewer on Kitchen Refit, which cannot move tasks between lanes.” An agent relays that to you instead of guessing at a workaround.
- Deletes are soft. A deleted task keeps its number forever and appears in the history, so “it deleted everything” is a state you can read, not a mystery.
- History is written by the service, never by a client. No agent can leave itself out of it.
- Revoking a token stops the agent at once and leaves its owner’s sign-in alone.
A setup that has never gone wrong for us
- Connect the agent with read and comment. Let it work a week: it reports what it would do as comments.
- Read the history on Friday. If every comment is one you would have acted on, tick write.
- Put the rules in the agent’s rules file (CLAUDE.md, Cursor rules): move to Completed only when tests pass; create a task for anything you notice; never delete.
- Keep AI context short and current, so the agent’s picture of how you work is yours and not its own.
The point
None of this makes the agent less useful. It makes it a colleague with a job description instead of a stranger with your password. The agent that files bugs from failing tests under a read-and-write role, signed, is more useful than one that can do anything, because you can let it run.