Nothing the assistant proposes is sent or deleted until you approve.

The assistant proposes first

Every command the assistant, a teammate or an App wants to run is first turned into a structured command. Anything that sends, deletes or changes records is shown to you as a plain-language preview before it runs. Background work waits in a queue for a member to approve it.

This matters for prompt injection. If a document, an email or a web page the assistant reads contains hidden instructions, the model can still be tricked into proposing a bad command. That proposal still has to pass the same preview and approval as any other, so it cannot silently send, forward or delete anything. Small, low-risk changes such as moving a widget apply without a prompt, and every one of them can be undone.

Scheduled agents and teammates can run while you are away, but what they propose waits in the Approvals queue. The one exception is opt-in and per teammate: a workspace admin can turn on auto-apply, and that teammate’s plain create and update changes to ordinary records are then applied without waiting. Auto-apply never sends, deletes, creates automations or touches invoices, payments, members or other sensitive collections; each change shows in Approvals with an Undo, and turning it on or off is written to the audit log. It is off until an admin turns it on.

How AI requests are handled

NATEX Work sends AI requests that use your plan only through OpenRouter, and only to model hosts that OpenRouter lists as zero-data-retention endpoints, meaning endpoints that keep no prompts or replies beyond serving the request, apart from the exceptions below. Every such request asks OpenRouter for both of its filters (zero data retention and no data collection), so if no such host can serve a request it fails instead of going elsewhere. NATEX does not train models on your content. It sends plan requests only to hosts that OpenRouter lists as zero-data-retention endpoints, which keep no prompts or replies to train on, apart from the exceptions below. If you choose to use your own AI account, requests on that account go to your provider instead, and your provider’s terms apply to them.

Those filters do not switch off a host’s own abuse and safety systems. For the hosts we use today:

OpenRouter keeps request metadata (such as token counts and timing) but not the text of your prompts or replies, and it may sample a small number of prompts to assign anonymous topic categories that are not linked to your account.

We never call the endpoints run by the Chinese model makers themselves (Z.AI, DeepSeek, Moonshot, MiniMax, Alibaba, Baidu and SiliconFlow). Open-weight models from those makers, such as GLM and Qwen, run on US-based hosts.

Web search is different: a short, cleaned search phrase (links, e-mail addresses and long numbers removed, never your workspace) goes to Perplexity through OpenRouter, and Perplexity states that it does not retain or train on API data. Voice input and live captions use your browser’s own speech recognition, run by your browser maker. Apps you connect (for example Gmail, Slack or Notion) are separate services with their own terms.

Your account is separate

Your NATEX Work account exists only because you created it here. Signing in to another NATEX product does not give it access to your workspace.

NATEX Work has its own database and sign-in system, separate from NATEX AI's other products. NATEX AI uses one Stripe account and one OpenRouter account for all of its products. Your NATEX Work data is used only by NATEX Work.

Isolation, export and delete

Each workspace’s records are isolated from every other workspace at the database level. The Privacy Center module lets you exclude collections or single records from the assistant, and Local-only mode (a switch in the Privacy Center and in Settings, Privacy) stops the assistant, search, Teammates, the App builder, Call Notes summaries, the setup chat and group-plan reasoning from making any AI call for you; the server refuses them, not just the screen. Settings, Account has Download my data and Delete my account.

Admin controls

Roles for admin, manager and member, a searchable and exportable audit log, and data-retention limits. Single sign-on and SCIM are not built.

Apps run in a sandbox with one way out

Apps you generate run in an iframe with only allow-scripts turned on. They get no same-origin access, no popups, no top-level navigation and no forms, so an App cannot read your cookies or session or send you anywhere.

The iframe has no network of its own: its content security policy blocks every outbound connection. The only way in or out is one message channel we check on every message. It must come from that exact iframe, carry a one-time value generated each time the App loads, and match one of a small set of allowed shapes. Anything else is dropped before it reaches application code.

What an App can read or write is decided by permissions it declares up front, which collections and which commands, and you approve that list before it first runs. Deleting a record or starting a teammate always stops for your confirmation, whatever the App declared.

Developer access uses the same rules

API keys belong to one workspace, carry a scope, can be limited to named collections and can expire. The REST API and the MCP server apply the same risk tiers as the interface: confirm-level commands return a plan and wait. See API and MCP.

Hard spending limits

Every workspace has a daily spending cap, and a kill switch turns the assistant off while the rest of the workspace keeps working.