What it is
PANTA OS uses a deliberately simple, two-layer permission model. The first layer is the role: every user is either an Admin or a User. The role determines whether a user can access the Admin Panel and configure the workspace. The second layer is assistant visibility: every assistant created in the workspace is either Private or Public. Visibility determines who can see and run a given assistant, independent of role. Together, role and visibility cover everything PANTA OS controls. There are no intermediate roles, no team-admin tier, and no separate “Builder” permission for creating assistants. Any user can build an assistant; only Admins can manage the workspace itself.Why it matters
A simple model is easier to operate and easier to audit. Three things are protected without permissions turning into a project of their own.Workspace control
Only Admins reach the Admin Panel, which is the single place where users, teams, integrations, branding, community posts, and token limits are configured.
Privacy of work
Assistants stay private by default. Publishing is an explicit step taken by the creator, not an automatic side effect.
Team-specific scoping
Public assistants can be assigned to specific teams by Admins, so an HR assistant can stay with HR even though it is technically workspace-wide.
No role sprawl
Two roles instead of four keep the model easy to understand. Promotion decisions stay simple.
The two roles
Admin
Full access to the Admin Panel. Manages users (User Management), teams (Team Management), tenant integrations (Integrations), workspace branding and identity (Organization Settings), posts in the community feed (Community Feed), workspace analytics (Analytics), and budget configuration (Token Limits).
User
Standard end user. Uses chats, assistants, and apps. Creates personal assistants through AI or Manual assistant creation. Reads and flags community posts. Authorizes personal integrations in Settings. No access to the Admin Panel.
What each role can do
| Action | User | Admin |
|---|---|---|
| Use chats, assistants, and apps | Yes | Yes |
| Create personal assistants | Yes | Yes |
| Upload knowledge files to your own assistants | Yes | Yes |
| Read community feed posts | Yes | Yes |
| Flag community feed posts | Yes | Yes |
| Create community feed posts | No | Yes |
| Authorize personal integrations in Settings | Yes | Yes |
| Access the Admin Panel | No | Yes |
| Manage users (User Management) | No | Yes |
| Manage teams (Team Management) | No | Yes |
| Configure tenant integrations | No | Yes |
| Edit workspace branding | No | Yes |
| Set token limits | No | Yes |
| Assign public assistants to teams | No | Yes |
Assistant visibility
Visibility is set on the assistant itself, in the Privacy Settings section of the assistant configuration. Two states exist; there is no team-specific or featured tier.Private
Default state for new assistants. Only the creator can see and run the assistant. Other users in the workspace are not aware that it exists.
Public
Visible across the entire workspace. Set by enabling “Make this assistant public” in the Privacy Settings. Once public, Admins can assign the assistant to specific teams through Team Management; users in those teams then see it in their dashboard grid.
How to use it
Change a user’s role
Edit the user
Click the edit icon next to the user in the table. Switch the role between Admin and User.
Make an assistant available to others
Switch to Public
Scroll to the Privacy Settings and enable “Make this assistant public”. Save with Save Changes.
Key settings and options
Two roles
Admin and User. Set per user in User Management.
Two visibility levels
Private (default) and Public. Set per assistant in the Privacy Settings.
Team scoping for assistants
Admins assign public assistants to specific teams in Team Management. This narrows who sees a public assistant without making it private again.
No intermediate roles
There are no roles for team admin, builder, or auditor. The two-role model covers every administrative scenario in PANTA OS.
Tips and best practices
- Keep the number of Admins small. Enough to cover absences, small enough that every Admin knows what the others are doing.
- Treat Private as the default for new assistants. Make an assistant public only after you have tested it and confirmed it does what you expect.
- If an assistant should reach just one team, make it public and ask an Admin to assign it to that team. Targeted reach is the standard way to scope; do not try to imitate team scoping by keeping an assistant private and sharing the link.
- Review who has Admin access during onboarding and offboarding cycles. The easiest place to do this is the Role column in User Management.
Help center
How many roles are there in PANTA OS
How many roles are there in PANTA OS
Two: Admin and User. There is no tier for team admin, builder, or auditor.
Where is the role set
Where is the role set
In the Admin Panel under User Management. Edit the user and select the role.
Can a user build assistants
Can a user build assistants
Yes. Any user can create their own assistants through AI or Manual assistant creation from the dashboard. No separate builder permission is required.
Can a user post to the community
Can a user post to the community
No. Posts in the community feed are created only by Admins through Admin Panel, Community Feed. End users can read and flag posts, but not post.
Are there team-specific roles
Are there team-specific roles
No. Roles apply workspace-wide, not per team. Membership in a team does not grant administrative rights within that team.
What visibility options exist for assistants
What visibility options exist for assistants
Two: Private (creator only) and Public (workspace-wide). Public assistants can be narrowed to specific teams by an Admin through Team Management. There is no featured tier.
Are role changes audited
Are role changes audited
PANTA OS does not currently provide an audit log for role changes. For regular reviews, check the Role column in User Management directly.