Ragenta Docs
Reference

Roles and permissions

The four built-in roles against every feature group, how permissions are named, and the rules for custom roles.

A permission is resource.action, e.g. document.create, billing.manage. Every screen and every endpoint checks a specific permission; a role is just a named set of them.

The four built-in roles

GroupOwnerAdminMemberViewer
View workspace, projects, knowledge bases, documents, conversations, agents, usage
Chat (chat.send), create/delete conversations
Create/edit projects (project.create/update), archive
Delete projects (project.delete)
Create/edit knowledge bases, upload/delete documents
Delete knowledge bases (knowledgeBase.delete)
Create/edit/publish/run/delete agents, control runs
Attachments, speech (attachment.*, speech.*)
Members, invitations, roles (member.*, invitation.*, role.manage)
Models (model.manage)
Connections, OAuth, data sources, MCP, webhooks, widgets (*.manage)
Billing, top-ups, promo (billing.manage, promo.redeem)
API keys (apiKey.*)
Read the credit ledger, invitations, webhook log, audit (transaction.read, invitation.read, webhook.read, audit.read)
Edit the workspace (workspace.update)
Delete the workspace (workspace.delete)

The app's own summary: Owner — Everything, including deleting projects; Admin — Members, billing and workspace settings; Member — Upload, chat and spend credits; Viewer — Read only — cannot spend credits.

Custom roles

  • A permission set the workspace defines, assigned in addition to the built-in role (the Extra roles cell).
  • Whoever creates a role may only include permissions they hold. Nobody grants what they do not have.
  • A permission can be narrowed to one specific resource (a project, a knowledge base, an agent) — a resource grant.

The hiding rule

A resource you may not see answers 404, not 403 — the system does not confirm something exists if you are not allowed to see it. Lists are filtered by workspace before anything is returned.

On this page