Organizations, roles and access
How organizations (tenants) are structured, the owner, administrator and user roles, the main administrator and the /admin console, SSO sign-in, permissions on knowledge bases and audit.
Gleyk supports several organizations in one installation. The data, settings, models, connectors and members of one organization are isolated from the others. This article describes the access model and where it is configured.
Organizations
An organization (the interface uses the word "tenant") is an isolated area of data and settings. An organization has a name, a set of default models (chat, embeddings, reranker, speech recognition, image description, service model), a root file folder, knowledge bases, assistants, agents, connectors, MCP servers and API keys.
A user can belong to several organizations and switches between them in the account menu. Before uploading a file or starting a conversation, check the active organization: resources of another organization are not visible, and this is normal behavior, not data loss.
Deleting an organization deletes all related objects: knowledge bases, documents, indexes, conversations, agents, connectors, tool servers, tokens and model settings. Restoring from the interface is not supported, so a backup is created before deletion.
Roles
| Role | Powers | Restrictions |
|---|---|---|
| Main administrator (superuser) | Creating and deleting organizations, viewing all users, assigning users to organizations, the license, system-wide settings | Given to the smallest possible number of trusted staff; not added to ordinary organizations as a member |
| Organization owner | Managing members and all resources of the organization, appointing administrators | Not assigned by the ordinary add-member operation; not used for daily work |
| Organization administrator | Managing members and resources of their own organization | Does not manage other organizations |
| User | Working with permitted assistants, knowledge bases, files, search and agents | Does not perform administrative operations |
| Invited | Waiting to accept the invitation | Powers are limited until the invitation is accepted |
Review permissions at least once a quarter and whenever duties change. Shared accounts are prohibited, except for a documented emergency account. It is better to do daily work and administrative work from separate accounts.
Admin console
The main administrator has access to the "Admin Console" at /admin:
/admin/tenants: managing organizations and their members, and the list of all users in the system. Here you add an existing user to an organization or create a new one with a temporary password and the role "User" or "Tenant Admin"./admin/audit: the log of actions across the whole system./admin/usage: token consumption and limits by organization and user./admin/license: license activation by token, including offline activation through a request file./admin/telegram: setup of the Telegram manager bot, through which organizations create their own bots.
Note
Removing a user from an organization does not delete their account if they belong to other organizations. Before removing a user, check whether they are the only person responsible for knowledge bases and connections.
Sign-in and SSO
Authentication is provided by an account service based on Zitadel (it is called Gleyk ID in the interface). The platform works with it over OIDC: the user signs in through a single sign-in page and gets a session, and roles are synchronized with the roles in the service. Multi-factor authentication is supported according to the organization's settings. Self-registration is turned off in a production installation (REGISTER_ENABLED=0): new accounts are created by an administrator or come from the corporate directory.
To connect a corporate directory, the account service is set up as a client of an external OIDC or LDAP provider. The service address, port and certificate are set during installation; for details, see the Software installation guide.
Permissions on knowledge bases and assistants
Within an organization, all its members see all of its knowledge bases: the current interface has no separate switch between a "personal base" and a "team base", and the access boundary is the organization. If materials must be shown to another organization, use knowledge base sharing, which is described in the article Knowledge base access and sharing. An assistant is bound to knowledge bases and can be open to all users of the organization or to selected users. An assistant's answer does not reveal documents that the user cannot access: this is one of the mandatory checks when you create an assistant.
Access to external systems is set separately. For each connector, a service account with minimal permissions is created in the external system, and for an MCP server each tool is turned on or off. Tools that change data are best turned off by default, and the remaining actions run only after the user confirms them.
Audit and limits
The action log is kept in a separate store where records cannot be changed, with full-text search. It records sign-in and sign-out, password changes, role assignments, creation and deletion of organizations and members, creation and deletion of knowledge bases and documents, permission changes, connector operations, tool calls and writes to external systems. The retention period is set by an installation parameter; events are also passed to an external log collection tool.
Token consumption is aggregated by organization, user, model and day. Limits in money or tokens per organization and per employee are checked before every model call; the limit status is visible in the interface.
Tip
After changing security settings, run a negative check: a user must not see another organization, and a service account must not read other people's secrets.
Related materials: On-premises installation, Private AI on-prem, the Security page.
Ask Sema