Access policies
A connection is possible only if a policy allows it. No policy — no access (default deny).
ALLOW and DENY
- ALLOW allows "who → to what": a device, user or group → a device or a device group. It can be limited by a schedule and an expiry date.
- DENY forbids and always wins over ALLOW. An active DENY can be disabled or deleted only by someone who may approve access to its targets (with a passkey); the platform administrator cannot do it.
A new allowing policy starts as "pending approval" and has no effect until it is approved with a passkey: by the owner (personal devices) or by a custodian of the management scope (managed devices).
Protection levels
| Level | What happens on connection |
|---|---|
| No extra admission | the policy is approved — the connection goes through at once |
| Owner approval to activate the policy | the owner or a custodian approves the policy once |
| Passkey confirmation before each protected session | every session is confirmed with a passkey in the panel |
| Passkey + live Telegram confirmation | both confirmations are needed before every session |
The device level is the minimum: a policy can only make it stricter.
Telegram confirmation
Link Telegram in Settings → Notifications. When someone connects to a protected device, the bot sends a request with "Confirm" and "Deny" buttons. The first answer of any custodian counts (except the initiator's, if there are several custodians).
If Telegram confirmation is required and nobody has Telegram linked, the connection waits and does not go through — this is intentional (fail-closed).
Change history
Every policy change is stored as a revision; history cannot be deleted or rewritten. In the connection log every session has a "Why allowed" button: the rule, its revision, who approved it and which confirmations were received.