PraxisOS personal assistant — what your approval actually covers

Where it runs

On the user's own machine.The assistant, its working memory and its access tokens run on the user's device — not on a Better Execute server. Setup installs standard developer tooling (the runtime, the assistant, and the tools it drives); there is no admin agent and no management backdoor. It makes outbound HTTPS to a short, fixed domain list and opens no inbound ports. The owner chats with it from their phone; the Telegram or WhatsApp desktop app is optional consumer software governed by your existing policy, and the assistant does not depend on it. Because it runs on the device, its outbound traffic is on your network and your own firewall can enforce the allowlist directly.

Access requested

Outbound endpoints (from the user's machine)

All connections are outbound from the user's machine — the core data path is HTTPS; the optional support layer uses Tailscale. No inbound ports. What your network needs to allow: outbound HTTPS to the list below.

Only one mail provider row and one messaging row apply to any given deployment. This table names the services involved so you can assess who processes data; it is not a copy-paste firewall rule. In the hosted deployment there is nothing for your firewall to allow, and for an on-device deployment we supply the exact enforceable host list for your tenant and channel as part of the arrangement.

Controls

Human approval, fail closed

Every outbound action (an email sent, a calendar change) requires the owner's explicit approval over an approved channel. If the approval prompt cannot be delivered — timeout, network failure, no channel configured — the action does not happen.

Least privilege

One mailbox. Read-only in the first phase. No send-as or send-on-behalf, no auto-send, no domain-wide access in the standard setup.

Revocable by you

Access is a standard OAuth grant visible in your Microsoft 365 / Entra ID or Google Workspace admin console. You can revoke it there at any time without contacting us.

Sensitive-category exclusion

Sensitive mail categories (HR, legal, personal, and similar) are excluded before any mail is ingested.

Support access, disclosed

With the standard support option, the user's machine joins a Better Execute support tailnet so faults can be fixed fast. We connect only when the user reports an issue and asks for help; access is scoped to that one machine and revocable by removing it from the tailnet. Support works from logs, health, and service configuration — and service config can include credentials, so treat this as vendor access to the machine, not a logs-only promise. Users who decline standing access are supported from logs they share manually today; a self-serve diagnostics bundle with secrets and message content stripped is being built to replace that, and we will not claim it here until it ships.

Logging, stated plainly

The workspace keeps an action log, and we will show it to you — but it is written by the system it describes and is not independently tamper-evident, and no external record proves the propose-approve-act sequence: your identity provider's logs establish token issuance and access windows only, and chat history is editable by participants. Treat the action trail as vendor-attested until tamper-evident logging ships.

To revoke access

Remove the OAuth grant in your Microsoft 365 / Entra ID or Google Workspace admin console, or ask the owner to disconnect it. Neither path needs anything from us. One caveat stated plainly, because it is true of OAuth generally: revocation stops new tokens being issued, but a bearer access token already in flight can keep working until it expires — typically up to an hour. Disabling the application or revoking the user's sessions stops anything new from being issued and is worth doing in an incident, but none of these steps retroactively cancels a token that is already out unless your tenant enforces continuous access evaluation. For incident planning, treat the token's remaining lifetime as the containment window.