An Access Control List (ACL) in Access Gate is the table that answers one question for every session: is this principal allowed to reach this asset over this protocol, right now? The table is editable per enclave, searchable across the whole deployment, and backed by your identity provider.
What an ACL Entry Looks Like
Each row ties five things together:
| Field | Example | Notes |
|---|---|---|
| Principal | alice@acme.com, group:ot-ops, asset A | A user, a group from your IdP, or another asset |
| Asset | plc-42.ot-cell-a, all assets in enclave | A specific asset or every asset in the enclave |
| Protocol | rdp, ssh, https, any | The protocols the session is allowed to use |
| Permission | allow, block | Default is deny — only allow rules open a path |
| Advanced Configuration | tls required, VPN allowed, Secured Remote Acces, Access Agreement | Specific configurations on top of Permission |
ACLs for Users
Adding every user individually does not scale well. Access Gate supports ACLs bound to user groups synced from your IdP — Entra ID, Okta, or Microsoft 365.
Add a group-based ACL
- Sync your IdP groups first: see Synchronize user directory (Entra ID).
- Navigate to Enclaves → [Your Enclave] → Access Control.
- Click Add rule.
- For Principal, pick Group and choose the IdP group.
- Pick the asset(s) and protocol(s).
- Save.
Group membership is re-evaluated on each session — the user does not need to log in again for a membership change to take effect.
Add specific ACL for a user
But if you want to manage your access at the user level, that works too!
Default Deny
Access Gate is default-deny: a session is rejected unless a matching allow rule exists. There is no implicit "members of the enclave can do anything" — every protocol on every asset is an explicit grant.
This means first-time enclave setup feels strict on purpose. Plan on:
- Creating the enclave and adding members.
- Turning on traffic inspection to see what the members actually try to do.
- Translating observed flows into ACL rules.
The Quick start walks through this loop.
Changes Are Audited
Every ACL edit lands in the enclave's change history (see Viewing enclave change history) with the operator, timestamp, and before/after values. Changes to access-screen permissions are recorded the same way.