Roles and access control

GVenta Kanban Board has two layers of access control: a system role that applies to the whole instance, and a project role that applies within each project. A separate AI agent flag changes how an account is presented, not what it can do.

System roles

Every user account holds exactly one of three system roles.

Role	Sees	Can create projects	Can manage users	Can access admin area
Admin	Every project, every story, every comment	Yes	Yes	Yes
User	Every project, every story, every comment	Yes	No	No
Restricted	Only projects they are an explicit member of	No	No	No

The first account ever created on an instance is automatically an Admin. Administrators assign roles to every account created after that; see Administration.

Admin

Administrators see everything and can do everything. They are the only users who can create, edit and deactivate accounts, change instance settings, choose the Git source provider, review resource consumption, and govern which file types can be uploaded. The Admin section of the sidebar (Users, Settings, Resources, File Types) is visible only to them.

User

A standard user sees every project, story and comment on the instance and can create projects, but has no access to the admin area and cannot manage other accounts.

Restricted

Restricted users see only the projects they have been explicitly added to as members. This is the mechanism for client access, contractors and narrowly scoped collaborators. Restricted users cannot create projects; an attempt to open the create-project form is refused.

How restriction is enforced

Restriction is not just a hidden menu item. Every list, search, filter dropdown, feed and API response is filtered against a restricted user’s accessible project set, including:

• the Projects list and the Dashboard
• the global story search and the story-ID resolver
• the global epic search
• the Comments feed
• the mentions bell
• another user’s public profile page, where the projects and stories shown are intersected with the viewer’s own accessible set
• the assignee dropdowns, which are narrowed to the people the viewer can actually see
• the automation work queues and every list and search endpoint in the REST API

Restricted users who are not members of a project are refused when they try to create a story in it. If a restricted user reaches something they are not permitted to see, the application renders a 403 page.

Why it matters: You can invite a client into one project and be confident they cannot learn about any other client’s work by searching, browsing comments, or looking at a colleague’s profile.

Project roles

Independently of the system role, each project member holds one of three project roles.

Project role	What it grants
Owner	Created the project or was granted ownership. Cannot be removed or demoted from the members screen. Can archive and restore the project.
Admin	Can add and remove members and change member roles.
Member	Ordinary participant.

Whoever creates a project is automatically enrolled as its Owner, whether the project is created from the web form or through the API.

Who can do what on a project

Action	Permitted to
Edit the project (name, description, repository, banner)	System admins, the project creator, any project owner, any project admin
Manage swim lanes	Anyone who can edit the project
Manage members	Project admins (and system admins)
Archive and restore the project	System admins and project owners
Delete the project	System admins and the project creator

The Members, Edit Project and Manage Swim Lanes buttons on the board header appear only for users permitted to use them. Non-privileged visitors can still open the Members screen and see the roster read-only.

Project deletion is a soft deactivation, not a permanent removal; see Automatic behaviors and safeguards.

Owner protection

The project owner is protected on the members screen: their role cannot be changed and they cannot be removed. This prevents a project from being orphaned by accident.

The AI agent flag

Any user record can be marked as an AI agent. This does not change permissions. An agent account holds a system role and project roles like any other account and is subject to exactly the same access rules.

What the flag changes is presentation. A small robot badge is rendered on the avatar everywhere the user appears: board cards, story detail, epic child tables, dashboard lists, assignee pickers, activity leaderboards and API payloads. The intent is that an agency can hand work to automation without ever losing sight of which items a human touched.

Administrators set the flag with the “Is AI agent” checkbox when creating or editing a user. For how agents typically interact with the board, see Pulse and AI agents.

Access control and the API

The REST API does not bypass any of the above. A bearer token acts with the permissions of the user who owns it, so every list, search and work-queue endpoint returns only what that user could see in the interface. Tokens additionally carry an ability list (read, write, admin) that further limits what the token can do; see API getting started.

Related pages

• Administration — creating users and assigning system roles.
• The project board — managing project members and project roles.
• Automatic behaviors and safeguards — owner protection, the self-deactivation guard and other integrity rules.