# Policies and permissions

- Link: https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/policies-and-permissions/
- Published: 2026-08-24T01:47:07+00:00
- Author: Don Bowman

1. [Home](https://www.agilicus.com/)
 2. [Agilicus AnyX Administrative Web Interface](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/)
 3. [Concepts](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/)
 4. Policies and permissions

![114ba8f7-featured-anyx-admin-conceptspolicies-and-permissions](https://www.agilicus.
com/www/114ba8f7-featured-anyx-admin-conceptspolicies-and-permissions.png)

## Policies and permissions

[CONTACT](https://www.agilicus.com/contact-us/)

The heart of Agilicus AnyX is _precise authorisation_: deciding, for each user and
each resource, exactly what that user may do. The portal gives you four related 
mechanisms: **permissions**, **policies**, **resource groups**, and **labels**.

## Users, groups, and service accounts

Access is granted to **identities**:

 * **Users** are people. Each user signs in through an identity provider.
 * **Groups** collect users so you can grant access in bulk and mirror the group
   structure from your identity provider.
 * **Service accounts** are non-human identities used by software and automation.

See [Users](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/users/),
[Groups](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/groups/),
and [Service accounts](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/service-accounts/).

## Permissions

A **permission** is a specific right on a specific resource or application:

 * for an **application**, permissions can be roles within the application (for 
   example _read-only_, _operator_, _administrator_);
 * for a **resource** such as a share or a desktop, permissions are access levels
   such as _read/write_ or _read-only_.

Permissions are granted per user or per group, and can be for a single resource 
or for a resource group. The portal separates:

 * [Application permissions](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/application-permissions/):
   who can do what within web applications; and
 * [Resource permissions](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/resource-permissions/):
   who can access resources and at what level.

    ```wp-block-agilicus-mermaid
    %%{init: {"theme": "base", "themeVariables": {"background": "#ffffff", "primaryColor": "#e8f1fb", "primaryBorderColor": "#1f4e79", "primaryTextColor": "#111111", "lineColor": "#4a4a4a", "secondaryColor": "#f5f5f5", "fontFamily": "Inter, sans-serif"}} }%%
    flowchart LR
        U[User] --> G[Group]
        U --> SA[Service account]
        G --> P[Permission]
        SA --> P
        P --> APP[Application role]
        P --> RES[Resource access level]
        RG[Resource group] --> RES
        LAB[Label] --> P
    ```

## Policies

A **policy** is a set of rules that control access beyond the basic permission grant.
Common policy rules include:

 * **geolocation rules**: allow or deny access based on the user’s location (for
   example deny access from specific countries);
 * **firewall rules**: allow or deny specific sources, paths, or conditions; and
 * **request rules**: require approval before access is granted.

Policies can apply to users or groups and can be linked to resources or labels. 
When a user requests a resource, the policy is evaluated together with the permission
grant. See [Policies](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/policies/).

## Resource groups

A **resource group** is a named collection of resources. Instead of granting permissions
one resource at a time, you grant permissions to the whole group. This is essential
when you have many resources (for example a fleet of desktops or a set of applications)
that should be managed together. See [Resource groups](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/resource-groups/).

## Labels

A **label** is a tag you can attach to any object. Labels let you organise resources
and users, and can be used by policies and permissions to grant or restrict access
by tag. See [Labels](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/organisation/labels/).

## The request flow

An administrator can enable a **request flow** so that users who do not yet have
access can request it. The request appears in the portal for an administrator to
approve or deny. Once approved, the user’s access is granted. See [Resource requests](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/resource-requests/).

    ```wp-block-agilicus-mermaid
    %%{init: {"theme": "base", "themeVariables": {"background": "#ffffff", "primaryColor": "#e8f1fb", "primaryBorderColor": "#1f4e79", "primaryTextColor": "#111111", "lineColor": "#4a4a4a", "secondaryColor": "#f5f5f5", "fontFamily": "Inter, sans-serif"}} }%%
    sequenceDiagram
        participant U as User
        participant P as Portal
        participant A as Administrator
        U->>P: Requests access to a resource
        P-->>A: Request notification
        A-->>P: Approves or denies
        P-->>U: Access granted or denied (recorded in audit)
    ```

## Combining the mechanisms

A typical configuration combines all of them:

 * a **group** of users with a shared role;
 * a **resource group** containing the resources they need;
 * a **permission** granting the group the appropriate level on the resource group;
 * a **label** such as _internal-only_ on the resources;
 * a **policy** denying access from restricted locations; and
 * the **request flow** enabled so new users can ask for access.

## See also

 * [What is Agilicus AnyX](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/what-is-agilicus-anyx/)
 * [Resources](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/resources/)
 * [Users](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/users/)
 * [Groups](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/groups/)
 * [Policies](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/policies/)
 * [Resource groups](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/resource-groups/)
 * [Resource requests](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/resource-requests/)

## Web guide

 * [Firewall rules](https://www.agilicus.com/product-guide/authorisation-rules)
 * [Geo-location-based access control](https://www.agilicus.com/product-guide/geo-location-based-access-control)
 * [Policies](https://www.agilicus.com/policies)
 * [Groups](https://www.agilicus.com/product-guide/groups)
 * [Resource groups](https://www.agilicus.com/product-guide/resource-groups)
 * [Permissions](https://www.agilicus.com/product-guide/permissions)
 * [Application request access](https://www.agilicus.com/product-guide/application-request-access)