Governance model
Four separate things decide what happens when someone uses the portal — who pays, which groups they're in, what their roles let them do, and who each resource is shared with.
Four separate things decide what happens when someone uses the portal: who pays, which groups they’re in, what their roles let them do, and who each resource is shared with. Keeping them apart is what makes the rules predictable. Where another page seems to disagree with this one, this page is right.
Key rules
- Departments pay — one per person: budget, limits and allowed models.
- Groups add roles and gather people for sharing. They never hold money.
- Roles are the only source of capability.
- Resources belong to the organisation, each with its own sharing rules.
- Deny always wins — even over the resource’s own owner.
The model in one picture
Every request answers the same questions, in this order. Step through them with a real person: Tran Mai, a contractor working with the Sales team.
Tran Mai is billed to Sales. Sales decides her budget, her limits and which models she can pick. Everyone has exactly one department — anyone not assigned yet sits in General.
The organisation — one per deployment — holds four kinds of thing:
| Part | How many per person | Relationship |
|---|---|---|
| Users | — | Provisioned from your identity provider through SCIMSCIM provisioningCấp tài khoản qua SCIMThe standard your identity provider uses to create, update and remove portal accounts automatically, so people who leave lose access.Open in glossary |
| Departments | Exactly one | Set each user’s budget, quota and blocked models; can be named in visibility rules |
| Groups | Any number | Grant roles to their members; can be named in visibility rules |
| Resources | — | Six organisation-level types, each with its own visibility rules |
Five questions
Every request passes the same gates. A failure at one gate stops the rest.
| # | Question | Answered by |
|---|---|---|
| 0 | Does this resource belong to the organisation? | Every operation; a mismatch answers “not found” |
| 1 | Who is the caller? | Identity |
| 2 | What may they do? | Roles and capabilities |
| 3 | Which things may they do it to? | Resource visibility |
| 4 | How much may they do? | Budgets and policy |
Roles answer the verbs and visibility answers the nouns. Question 4 returns a quantity — a budget, a limit — so it has its own rules rather than reusing roles. Question 0 runs even for the Org Owner.
Worked example: deny wins
Tran Mai asks why she can’t find the Pricing Assistant agent everyone in Sales talks about. Here is what the portal sees.
| The person | The resource (agent) |
|---|---|
| Tran Mai · mai.tran@ecloudvalley.com | Pricing Assistant |
| Department: Sales | Owner: Le Minh · Restricted |
| Groups: Contractors, Sales Research | Allow: Sales |
| Role: Org User | Deny: Contractors |
-
Her account is active and the agent exists — continue
The caller resolves and the resource belongs to the organisation.
-
A deny rule matches — she's in Contractors → hidden
Deny is checked first and ends the check.
-
The Sales allow rule is never reached — skipped
Being in Sales doesn’t rescue her, and nor would owning the agent.
To give her access, take her out of Contractors or remove the deny rule — adding another allow changes nothing. See the full rule order on Resource visibility.
Departments and groups at a glance
They look alike in a list of people, so they’re the pair most often confused. They answer different questions.
| DepartmentDepartmentPhòng banThe bucket that pays: it owns a budget, limits and which models its people may use. Everyone belongs to exactly one.Open in glossary | GroupGroupNhómA set of people used to give roles and to name in sharing rules. A person can be in many groups; a group never holds money.Open in glossary | |
|---|---|---|
| Answers | Who pays, and how much? | What extra can they do and see? |
| Per person | Exactly one — General if unassigned | Any number |
| Holds | Budget, limits, blocked models | Custom roles |
| In sharing rules | Yes | Yes |
| Never | Grants a capability or owns a resource | Holds money or counts as a department |
A department owns quota, budget, the chat models it blocks, cost attribution and default policy, and maps to a LiteLLM team that carries the budget. Its membership is a direct list of users. General is the seeded system department: it receives anyone with no other assignment, so every request has exactly one bucket. A person can be given limits of their own, which replace the department’s for that person — their spend is still billed to the department, and the models the department blocks stay blocked for them. See Budgets and policy and Departments.
A group bundles custom roles and is referenced by visibility rules. People may also hold custom roles directly; their capabilities merge with their organisation role and the grants from every group. See Groups.
Resources
There are six organisation-level resource types: agents, skills, prompts, applications (the Connected apps people use), artifacts and knowledge bases. None is owned by a department. An owner is either the system or a user, and access comes from each resource’s own rules: open to the whole organisation or not, plus allow and deny lists naming departments, groups or users. The exact rule order is on Resource visibility.
- Visibility never grants a capability, a model, a quota or an application permission.
- Everything filed under a knowledge base — each memory statement and document excerpt — inherits the knowledge base’s answer.
- Your own memories sit in a knowledge base you own, with no rules and no listing.
Admin tier
There is no team-role tier: no TEAM_OWNER, no TEAM_ADMIN. Org Admins manage departments.
An invitation asks for a department and a role on one form, and they mean different things:
- The department is the budget the person is billed to. The field says so: it buys no authority.
- The role is authority over the whole organisation. The interface calls the administrator role Organisation admin, everywhere.
Four capabilities are non-delegable: they stay on built-in roles and can never be put on a custom role.
| Capability | Held by | Delegable? |
|---|---|---|
org.settings.manage | Org Owner, Org Admin | No |
billing.manage | Org Owner only | No |
user.impersonate | Org Owner, Org Admin | No |
impersonation.approve | Org Owner, Org Admin | No |
How the ceiling is enforced: Roles and capabilities › The grant ceiling. How View as works: Access approvals › Impersonation.
Directory mode
Each organisation picks a directory mode once, when it is created:
PORTAL— the portal owns who exists, their groups and their department.IDP— an external identity provider owns them, while permission to use AI features stays with the portal.
Which writes each mode freezes, and how an IDP organisation fills departments from provider groups: Departments › Directory mode.
Why it works this way
Why aren't departments and groups the same thing?
Money needs one answer; permissions don’t. If groups carried budgets, someone in three groups would have three budgets and nobody could say which one paid. One department per person gives every model call exactly one bill, while groups stay free to overlap.
Why can't a department own an agent?
A department answers one question — who pays — and each person sits in exactly one. If departments owned agents, moving someone to another budget would quietly change which agents they can use. So agents belong to the organisation, and each agent’s sharing rules can still allow or deny a whole department.
Why does deny beat ownership?
So one rule can take something away, whoever set it up. A compliance reviewer can pull a resource from a group without changing who owns it, and no allow rule, org-wide switch or ownership can quietly undo that.
Why does a hidden resource look like it doesn't exist?
Saying “forbidden” would confirm it’s there. The portal answers “not found” for a missing and a hidden resource alike, so a list, a link or a guessed address never reveals what you aren’t meant to see.
Under the hood
Organisation id and status codes
Every root table carries the organisation’s id. The organisation check (question 0) runs before anything else, even for an Org Owner. An outsider gets 404 rather than 403, because a 403 confirms the id exists. 403 means “it exists but you may not”; 404 means “you are not entitled to know”.
Put it into practice
Assign departments Bill people to the right budget. 
Create a group Gather people for roles and sharing. 
Give a custom role Grant a narrow set of capabilities. 
Share an agent Allow or hide it for people and teams. 
Set budgets and limits Decide what each department spends. 
Review access requests Approve budgets and transcript reads.