Permissions

Polygent authorization combines role permissions, workspace membership, ownership rules, and an administrator bypass.

Access model

A permission answers what a user can do; workspace membership answers where the user can do it.

For workspace-scoped data, a non-administrator normally needs both the relevant permission and membership in the workspace. Ownership-sensitive features can additionally distinguish the user's own sessions or automations from all records. The UI hides unavailable actions, but the server remains authoritative and rejects unauthorized requests.

Control	Effect
Role permissions	Grant capabilities; permissions from multiple assigned roles are combined.
Workspace membership	Limits visible and actionable workspace data.
Own versus all permissions	Limits access to records owned by the user unless broader access is granted.
Administrator	Bypasses permission, ownership, and workspace checks.

The first user to sign in becomes an administrator. Protect that account, assign at least one additional trusted administrator, and use non-administrator accounts for routine work.

Permission reference

The Roles permission matrix is the authoritative list for the installed version.

Area	Permissions
Administration	Administrator; View/Manage Users; View/Manage Settings; View Statistics.
Sessions	View Own/All, Create Sessions, create Chat, create Develop, Edit, Delete, Manage All, Merge to Starter.
Workspaces	View, Create, Edit, Delete, Manage Workspace Users.
Tickets	View, Manage, Developer Approval, QA Approval, Skip to Merge.
Hosts	View Hosts, Manage Hosts, Manage Host API Keys.
Workflows and bots	View/Manage Workflows; View/Manage Bots.
Harness content	View/Manage Skills, Subagents, MCP servers, and Memory; manage personal Polygent Code settings.
Planner	Create Plans, View All Plans, Manage Plans.
Automations	View Own/All, Manage, Manage All.
Insights	View, Manage.
Merge conflicts	View, Manage.
Round tables	Create, Manage Personas.

Some capabilities also depend on license features and the state of the target record. A permission grants eligibility; it does not override a disabled feature, invalid state transition, repository protection, or external-provider access.

Manage roles

Roles are reusable permission bundles managed in the Users area.

1. Open Users → Roles with Manage Users access.
2. Create a role with a purpose-specific name.
3. Select only the permissions required for that job function.
4. Assign one or more roles to each user.
5. Add non-administrators to the workspaces they need.
6. Test with a non-admin account before broad rollout.

A role cannot be deleted while assigned to users. Remove assignments first. Role changes apply to all assigned users, so review membership before expanding a shared role.

Manage workspace membership

Workspace membership is the tenant boundary for non-administrators.

Open the workspace's Users or Members tab and add or remove users with Manage Workspace Users. Removing membership hides that workspace's scoped resources but does not delete the user's account, roles, authored records, or historical attribution.

Administrators see every workspace without explicit membership. Do not grant Administrator to solve a missing-membership issue; add the user to the required workspace instead.

Recommended role baseline

Start with narrow roles and add capabilities only when a verified workflow requires them.

Role	Recommended scope
Supporter	View users, workspaces, sessions, tickets, hosts, statistics, insights, and merge conflicts; add management permissions only for owned operational duties.
Developer	Create and edit sessions, view own sessions, view tickets, perform developer approval, and view approved workspace tools.
QA reviewer	View sessions and tickets, perform QA approval, and view statistics for assigned workspaces.
Deployment operator	View and manage hosts and slots, without Host API Key management unless credential rotation is part of the role.
Security administrator	Manage users, roles, settings, and host API keys; avoid routine development permissions where separation of duties is required.
Read-only stakeholder	View-only permissions for the required modules and workspaces.

Avoid wildcard-style assumptions: the matrix contains explicit permissions. Review new permissions after every upgrade; existing custom roles do not automatically express your intent for newly added capabilities.

Security operations

Authorization changes are security-sensitive configuration.

• Keep Administrator and Manage Users, Manage Settings, Manage Host API Keys, Skip to Merge, and deployment management narrowly assigned.
• Separate credential management from day-to-day worker or slot operation where possible.
• Remove workspace membership and roles promptly during offboarding.
• Revoke active devices and external personal access tokens separately; role removal alone does not revoke every credential.
• Record and periodically review role membership against current job responsibilities.
• Test denial as well as success: confirm a user cannot see unrelated workspaces or perform destructive actions.

Troubleshooting

Access problems are resolved by checking permission, membership, ownership, license, and target state in that order.

Symptom	Resolution
Workspace is missing	Add the non-admin user to Workspace → Members.
Action is hidden or access is denied	Grant the exact permission through an assigned role and confirm workspace membership.
User can view only some sessions	Grant View All Sessions if justified; View Own Sessions intentionally limits scope.
User cannot manage another user's automation or session	Grant the corresponding broader manage permission rather than Administrator.
Role cannot be deleted	Remove the role from all users, then delete it.
Permission appears correct but feature is absent	Check the installed license and whether the feature is enabled and configured.
Administrator sees data outside assigned workspaces	This is expected; Administrator bypasses workspace membership. Use a non-admin role for scoped operation.
User retained an external capability after offboarding	Revoke identity-provider sessions, personal access tokens, host keys, and repository/provider credentials separately.