Exponential Rules

Exponential Rules grant access based on resource attributes, not on individual resources. You write one rule such as "the DBA group can connect to every server tagged production", and it applies to every matching resource, including resources added later.

Rules are managed under Policies › Exponential Rules in the GAccess console.

Exponential Rules only ever add access. They never remove access a user already has through roles or resource permissions.

---

Rule structure

A rule has a name, an optional description, an enabled toggle, and one or more statements. Each statement is evaluated on its own. A user gets the statement's access if they match that one statement.

Each statement has three parts:

Part	Defines
What	The resource type, the permissions to grant, and the filters that select resources.
Who	The users and groups the statement applies to.
When & how	Optional conditions: MFA, source network, and schedule.

To reuse a statement for another resource type, use Copy to other resource types on the statement card.

---

What: resources and permissions

Resource type and permissions

Resource type	Available permissions
Server	Connect, Read, Manage (full control)
Credential	Connect, Read
Application	Connect, Read, Manage (full control)

Credential statements can't grant Manage, because it includes revealing the stored secret. A filter-based rule could otherwise hand that ability out for credentials that don't exist yet.

Resource filter

Filters select which resources the statement covers. All filters must match. While you edit, a live preview shows how many resources currently match, with a few examples.

Resource type	Filterable fields
Server	Name, IP address, Category, OS, Tags
Credential	Name, Type (Local, Domain, Private Key, API Key, Application), Tags
Application	Name, Type, Tags

Field kind	Operators
Text	is, is not, contains, starts with
Type	is, is not, is any of
Tags	has any of, has all of, has none of

Tag your resources consistently (for example env:production or team:finance). Tags are the most reliable way to target groups of resources.

---

Who: users and groups

Select at least one user or group. A statement with no subjects is rejected, so a rule can't silently grant access to nobody.

Group membership is checked on every request. Users added to a group get the group's access right away, and users removed from it lose that access.

---

When & how: contextual conditions

All conditions are optional. When you set more than one, the user must meet all of them. If a condition isn't met, the statement grants nothing. Other statements and the user's other access are unaffected.

Condition	Behavior
Require MFA	The user must have MFA enabled and have signed in with a username and password. Users who sign in through SSO don't meet this condition.
Allowed source networks	The user's IP address must fall within one of the listed IPv4 CIDR ranges (e.g. 10.0.0.0/8). IPv6 addresses don't match.
Schedule	Access applies only on the selected days and time ranges in the chosen timezone. If no days are selected, every day matches. If no time ranges are set, any time matches.

Conditions are checked every time a user requests access. Access stops as soon as the user leaves the allowed network or schedule.

---

Example

Goal: Database administrators can connect to production Linux servers during business hours, from the corporate network only.

Setting	Value
Resource type	Server
Permissions	Connect
Filter	Tags has all of production, database · OS contains Linux
Who	Group DBA
Require MFA	On
Allowed source networks	10.0.0.0/8
Schedule	Mon–Fri, 08:00–18:00, America/Sao_Paulo

A new server tagged production and database that runs Linux is covered as soon as it's added. You don't need to edit the rule.

---

Disabling or deleting a rule

Turn off Enabled to suspend a rule without losing its configuration. Deleting a rule removes the access it granted. Access that users hold through roles or other rules is unaffected.

All rule changes are recorded in the audit log.