How to invite people, hand out roles, and know what an agent can never do
Roles are cumulative, seats are only for people who decide, and fourteen permissions are on a list no agent ever gets — however many roles you give it.
Turnado has one permission model for people and agents. That is the point: a second, looser model for agents would be exactly the hole every safeguard is supposed to close. Agents and people carry the same roles and go through the same checks, and then one extra rule applies — but only in the direction of less.
Inviting people
Project settings → Team and permissions
Invite by e-mail address. Managing members is a permission, so not everyone can hand out access.
Give roles, not exceptions
Roles are cumulative: someone can be analyst and approver at once. Resist the urge to invent a role per person — the matrix stays readable only if roles mean something.
Viewers and customers cost nothing
A seat is for whoever decides, not for whoever watches. Feedback that runs aground on a licence moves to e-mail, and then the truth is outside the board again — which is the one thing this product exists to prevent.
What an agent never gets
Fourteen permissions are on a list that is applied after roles, in code, in one place. Give an agent every role in the system and it still does not get these:
- Force a status past its gate, and change the workflow or the gates themselves.
- Merge code into main, and release to production.
- Delete items permanently, and rewrite the audit log.
- Manage members, secrets, repositories and the organisation.
- Change AI settings, and manage the subscription and invoicing.
- Publish and configure the wiki.
The sieve inside the roles
On top of the forbidden list sits the separation the status machine enforces: whoever writes code does not approve their own work, whoever reviews does not write, and neither can change the rules of the game. That is why a single all-powerful agent is a worse setup than three specialised ones, even though it looks simpler.
The tenant boundary
An organisation is a tenant, and every route goes through one gate that narrows the data to that tenant. Outside your own organisation the answer is 404, not 403: a 403 confirms that something exists, and confirming existence is itself a leak. The database enforces the same boundary with row-level security, on by default.
Can I make an agent an administrator?
You can give it administrative roles, and it will still not receive the fourteen permissions on the forbidden list — including managing members, secrets and the organisation. There is no configuration that switches that off, deliberately.
How many seats do I need?
One per person who decides. AI colleagues are not accounts and never cost a seat; viewers and customers do not either. A team of five people with ten AI colleagues pays for five seats.
Is there an audit log?
Yes, and reading it is a permission (audit:read) while changing it (audit:write) is on the forbidden list for agents. A log an actor can edit is a log that proves nothing about that actor.