How it handles company data.
Six things it does with your company's data, in plain words, and where each one stops.
Every tool is a switch you hold
A connected app lists every tool it offers, each with a switch, in your own account; they start switched on. Nothing a run does can turn one back on. If there is a tool you never want used, such as a send, a delete or a refund, switch it off. It stays off whatever anyone later configures.
Open this answer on its own page: Every tool is a switch you hold
Review any app, when you want it
The control is the switch: each person connects their own account and decides, tool by tool, what Ara may do with it. Nothing outside that ever runs. On top of that, a workspace admin can put any app under review, so every change in it is previewed and waits for a member's approval, or block an app outright. Review is opt-in, so approval queues stay short enough to be read. Every action is written to the run record either way.
Open this answer on its own page: Review any app, when you want it
Works in its own sandbox
Code the model writes runs in a sandbox, never on our API servers, and each workspace has its own. Outbound network access from the sandbox is open unless the deployment restricts it to a list of hosts. A workspace that makes one of its own PCs the workspace computer runs commands on that PC instead.
The model never sees your keys
The credentials we hold, such as Slack tokens, API keys, access to your own AI plan and saved website passwords, are encrypted at rest (AES-256-GCM). Apps connected through Composio keep their tokens at Composio. None of these reach the model or the run log, and no app token or API key is put in the sandbox. A saved website password is the exception: it is written into the sandbox for the moment it is typed into the page, and code running there at that moment could read it.
Open this answer on its own page: The model never sees your keys
Treats the web as data, not orders
Web pages, connected apps such as email and ticketing, and searched documents reach the model marked as quoted data, with the rule to report what they say and never act on it. A run started by an inbound event is told so explicitly, and told to draft rather than act when the payload seems to ask for something outward-facing. This lowers the risk that a planted sentence steers a run; it does not remove it, which is why the switches and reviews above exist.
Open this answer on its own page: Treats the web as data, not orders
We never train models on your data
Customer data is used to do your workspace's work, including what Ara remembers for its next task there, and we do not train AI models on it. Requests reach model providers through OpenRouter, and whether a provider may keep or train on one is set by that provider's terms and the OpenRouter account's privacy settings. A deployment can also have every request refuse providers that keep data; that is not on by default.
Open this answer on its own page: We never train models on your data
Where it can be wrong
Like any model, Ara can be wrong. That is why work comes back with the steps it took and a file you can check, why every run is on record, and why you decide tool by tool what it can reach at all.
Hand Ara the job you keep putting off.
Bring your team's first AI employee into the chat you already use and give it one job. It comes back finished. Free to start, no card.