# Access control

## Three-layer access model

Access in Peig is enforced at three independent layers. All three must be satisfied for access to be granted:

| Layer       | Enforced by                                           |
| ----------- | ----------------------------------------------------- |
| **User**    | Account must be active — not suspended                |
| **Device**  | Device must be registered and not suspended           |
| **Service** | User must be explicitly granted access to the service |

This means that compromising one layer is not enough to gain access. A valid user on a suspended device cannot access anything. A registered device belonging to a suspended user cannot access anything. A user and device that are both active cannot access a service they have not been granted.

***

## Policy Enforcement Point

Every access request flows through the workspace **Policy Enforcement Point (PEP)**. The PEP checks every request against the three-layer access model before allowing it through to the target application. This enforcement is consistent across all connected services — a user cannot bypass it for one application while being bound on another.

***

## Least privilege by design

Access to each connected service must be explicitly granted per user. There is no default access and no "grant everything" option. Users can only see and access the services they have been given — nothing else is visible to them in their workspace dashboard.

This enforces least privilege at the architecture level, not just as a policy recommendation.

***

## Revocation

Access can be revoked at any of the three layers, immediately and independently:

* **Suspend a user** — blocks access across all their devices and all services simultaneously
* **Suspend a device** — blocks access from that specific device only; the user's other devices and account are unaffected
* **Toggle off a service** — removes access to a specific application for a specific user; all other access is unaffected

All revocations take effect immediately. There is no token expiry to wait for and no residual access window.

***

## Admin roles and separation of duties

| Role             | Scope                                                    |
| ---------------- | -------------------------------------------------------- |
| **Global Admin** | Configures which services are connected to the workspace |
| **Access Admin** | Manages users, devices, and access rights                |

These roles can be held by the same person or separated across different individuals — supporting separation of duties for organisations that require it.

***

## Audit trail

Every access event and every administrative action is logged:

* User accessed a service — which user, which service, which device, timestamp
* Access denied — unregistered device, suspended user, suspended device
* Admin actions — access granted or revoked, device registered or removed, user suspended or unsuspended, onboarding request approved or denied

Access Admins also receive email notifications for all significant events, providing a secondary timestamped record alongside the system logs.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.peig.io/welcome-to-peig-documentation/security/access-control.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.