Access Control Overview
Access Control determines what each user can see and do across grengin. It is built on two concepts that work together: permissions and roles.
How it works
Permissions are the building blocks. Each permission represents a single allowed action on a specific part of the platform — for example, viewing budget data or managing departments. Permissions are either global (platform-wide) or department-scoped (limited to specific departments).
Roles bundle permissions and are assigned to users. A user’s effective access is the combined set of all permissions from every role they hold.
Permissions → bundled into Roles → assigned to Users
Permissions are not assigned to users directly. You manage access from Control Hub → Access Control, which has two tabs:
| Tab | Purpose |
|---|---|
| Roles | Create and manage roles, assign users, and configure department scoping per user |
| Permissions | Read-only reference of every permission available in your organization |
Global vs department scope
In the Permissions tab, each permission is labeled Global or Department:
- Global — applies across the entire platform. Users with a global grant are not restricted to specific departments.
- Department — can be limited to one or more departments per user. The same permission can mean different things for different users: someone with
Budget: Viewscoped to Finance only sees Finance budgets, not Engineering’s.
For department-scoped permissions, configure restrictions per user from Access Control → Roles. Expand a role’s user list and choose Manage scoping to assign specific departments or Assign all departments for unrestricted access within that permission.
Scope is a property of the permission itself. You do not change whether a permission is global or department-scoped — you configure department restrictions when assigning roles to users.
What users experience
Access Control shapes the interface each user sees — not just what they can do, but what appears at all.
Control Hub entry
The Control Hub link in grengin chat is only visible to users who hold at least one permission. Users with no permissions (for example, the default User system role) cannot see or open the Control Hub.
Sidebar navigation
Inside the Control Hub, sidebar items appear only when the user has the required permission. Restricted sections are hidden entirely. Items are grouped into Overview, Monitor, Manage, Configure, and Settings sections depending on access.
Page access vs actions
View permissions gate access to a page. Manage, Allocate, Assign, and similar action permissions control buttons and workflows within a page. A user who can open a page but lacks an action permission will see the page in read-only form — edit, delete, allocate, and similar controls stay hidden.
Direct URL access
If a user navigates to a restricted page directly, they see an Access Denied (403) page instead of the content.
Landing page
When opening the Control Hub, grengin sends users to the first page they can access — typically Overview for users with global analytics access, otherwise the first permitted section (such as Organization, AI Engines, or Access Control).
Control Hub pages and permissions
| Control Hub area | Required permission | Notes |
|---|---|---|
| Overview | Analytics: View (global) | Requires platform-wide analytics scope |
| Usage Analytics | Analytics: View | Department scope filters reported data |
| Prompt Metrics | Analytics: View | Shown with Usage Analytics |
| Organization | Users: View and/or Departments: View | Users and department management |
| AI Engines | AI Platform: View | Manage actions need AI Platform: Manage |
| Connectors | MCP Servers: View | Admin and Delegate control MCP configuration |
| Access Control | Roles: View | Creating roles needs Roles: Manage; assigning users needs Roles: Assign |
| Prompts | Roles: View | Prompt library management |
| Audit Logs | Audit Logs: View | Platform audit trail |
| Settings | SSO Providers: View | SSO configuration; System: Maintain unlocks host maintenance |
Budget visibility and allocation are managed within Organization (departments) and require Budget: View and Budget: Allocate respectively.
Managing access
Typical workflow:
- Review the built-in system roles and choose one that fits, or create a custom role.
- Assign the role to users from Access Control → Roles.
- For department-scoped permissions, open Manage scoping on each user and assign the relevant departments.
- Use the permissions reference when building custom roles.
Users can hold multiple roles. Their access is cumulative — if any role grants a permission, the user has it.
Next steps
- Permissions — permission domains, actions, scope types, and the full reference table.
- Roles — system roles, custom roles, and step-by-step role management.