Overview

Permission Sets are how Ejento AI controls who can see and do what inside your organization. Instead of granting access to each user one resource at a time, you define a reusable Permission Set once — a named bundle of access rules — and then assign it to the people who need it. Every user attached to that set inherits exactly the access it defines, and any later change to the set applies to all of them at once.

Each Permission Set is built from scopes. A scope answers three questions for a given assistant:

View scope — which assistants the user is allowed to see.

Edit scope — which assistants the user is allowed to modify.

Delete scope — which assistants the user is allowed to remove.

Deploy scope — which assistants the user is allowed to deploy changes to production.

Scopes are usually narrowed to a boundary like "Assistants they own", so a user can manage their own resources without touching anyone else's. Sensitive actions — most notably deploying changes to a live assistants — are gated separately, so a user may be able to edit a configuration but still be prevented from pushing it to production until an administrator approves.

Roles vs. Permission Sets

Ejento AI controls access through two complementary layers. Understanding the difference is key to setting people up correctly.

Account roles — a broad tier assigned to each person that sets their baseline reach across the organization.

Permission Sets — fine-grained, reusable rules layered on top of a role that decide exactly what a person can create, view, edit, delete, and deploy for which specific assistants.

A useful way to think about it: roles decide how far someone's authority extends; Permission Sets decide exactly what they can touch within assistants.

The account roles

Role	Scope of control	What they can typically do
Global Admin	The entire organization	Full control: manage all users, teams, projects, assistants, and corpora; configure organization settings; create and assign Permission Sets. This is the highest level of access.
Application Admin	Application-level functions and resources	Elevated administrative access over many areas and shared resources, but without full organization-admin authority. Sits below a Global Admin.
User	Only the resources they own or are granted	Works within their own assistants, projects, and corpora, plus anything explicitly shared with them.

Note: On any individual resource (a specific assistants, team, or project), a user can additionally hold an Admin or Member access, which further refines what they can do with that one item — independent of their org-wide role.

How Permission Sets fit on top

Roles set the ceiling; Permission Sets carve out the precise access beneath it. Assigning someone the "User" role doesn't, by itself, say what they can do to which assistants — the Permission Sets you attach to them do.

High-impact actions stay gated. Even a user who can edit a configuration may be blocked from deploying it to a live environment.

In short: use roles to establish broad trust levels (who is an admin vs. a regular user), and use Permission Sets to precisely define what each user can see and change within assistants.

Directly Shared Assistants

Permission Sets grant scoped access across whole populations of assistants, but an assistant can also be shared directly with an individual user — or with every user in the organization at once, by making the assistant Public.

A direct share does not grant actions by itself. It names which assistant a user may act on; the actions they can actually perform still come entirely from the Permission Sets they hold. In other words, a share opens the door to a specific assistant, but the Permission Set decides what the user can do once inside.

A direct share is granted at one of two levels:

Share level	What it can unlock (given a matching Permission Set)
member	View only.
admin	View, edit, delete, and publish.

How access resolves

For each action, a directly-shared user's access is the intersection of their share level with their capability for that action.

A capability is the scope-agnostic union of every scope grant the user holds for that action across all of their assigned Permission Sets — in plain terms, "does this user have view (or edit, delete, publish) at any scope?"

Member share — the user can view the assistant if they hold any Permission Set that grants view at any scope. A member share contributes nothing to edit, delete, or publish.

Admin share — the user can view, edit, delete, or publish the assistant, action by action, if they hold any Permission Set that grants that same action at any scope. An admin share never unlocks an action the user has no Permission Set for.

Public Assistants

Public assistants are shared with all users in the organization at once, at member access. Every user then resolves against their own view capability individually — so only members who already hold view somewhere gain access. Making an assistant Public does not override the Permission Set requirement; it simply extends a member-level share to everyone.

Note — team shares differ: A direct share to a team behaves slightly differently — it is gated at team scope rather than by the scope-agnostic capability. The capability-based resolution described above applies to shares made directly to an individual user.

Key takeaway: a share (direct or Public) answers "which assistant?"; the user's Permission Sets answer "which actions?" Access is only granted where the two overlap.

System and default Permission Sets

Not every Permission Set behaves the same way. Two special categories carry rules you can't override, and there are a few organization-wide limits worth knowing before you start creating sets.

System Permission Sets

System Permission Sets cannot be modified. Their scopes are fixed. You can, however:

Set/Unset them as default (on/off), and

Assign or remove users.
You just can't change what the set grants.

Default Permission Sets

A default Permission Set is one that is automatically assigned to every new user added to the organization, so people start with a baseline of access from day one. Because of this, defaults follow special rules:

An organization must always have at least one default Permission Set.

The last remaining default cannot have its default field toggled off — this guarantees the organization is never left without a default. (Once another set is marked default, the previous one can be freely toggled again.)

Turning a set's default on or off changes only future assignments to new users; it doesn't retroactively add or remove the set from existing users.

Assignment limits

A user can have at most 20 Permission Sets assigned at any one time. Plan for this ceiling when designing sets — favor a smaller number of well-scoped sets over many narrow ones.

Quick reference
Rule Detail
System sets Scopes are locked; only the default toggle and user assignments can change.
Minimum defaults At least one default must always exist in the organization.
Last default Its default field cannot be toggled off while it's the only default.
New users All default sets are auto-assigned to every new user.
Per-user limit Maximum of 20 Permission Sets per user at a time.

Rule	Detail
System sets	Scopes are locked; only the default toggle and user assignments can change.
Minimum defaults	At least one default must always exist in the organization.
Last default	Its default field cannot be toggled off while it's the only default.
New users	All default sets are auto-assigned to every new user.
Per-user limit	Maximum of 20 Permission Sets per user at a time.

Roles vs. Permission Sets#

The account roles#

How Permission Sets fit on top#

Directly Shared Assistants#

Share levels#

How access resolves#

Public Assistants#

System and default Permission Sets#

System Permission Sets#

Default Permission Sets#

Assignment limits#