What the agent can do and where data is stored

This page covers how control works in each product, what is on by default and what you should configure yourself. Liho has no compliance certifications or SLA; we describe only how the products work.

Liho Cowork

By default. A new task runs without isolation, in the “Auto” approval mode and with full network access. That is convenient for your own files, but for untrusted documents and websites you should tighten the settings: the agent reads their content and may mistake text in them for an instruction.
Folders
The agent sees only the folders opened for the task and the task’s working folder. Each folder is either read-only or read and write. Access outside the workspace is requested separately.
Approvals
“Always ask”: every action waits for an answer. “Auto for reads”: reading needs no answer, changes and commands need approval. “Auto”: files and commands without asking. Computer control and actions in external services require approval in every mode, and permission requests cannot be handed to another agent.
Isolation on macOS
Process sandbox: the agent sees only the selected folders, and network access goes only through a proxy.
Isolation on Linux
A process sandbox based on bubblewrap with system call restrictions. Requires the bubblewrap and socat packages.
Isolation on Windows
A WSL2 virtual machine with a separate distribution, or a process sandbox. The Windows process sandbox limits writes to the selected folders, but reads files as you and does not restrict the network.
Network
For a task you can allow only Liho LLM, a list of domains, or full access. The restriction works in the macOS and Linux sandbox and in the Windows virtual machine.
Schedules
Scheduled tasks on a computer run only with isolation; without it, the schedule will not start.
Data
Chats of tasks on a computer are stored on that computer. Tasks on a server and their files are stored on the server.
Remote control
Turned on separately on each computer. A new device is confirmed on an already trusted one with a six-digit code; the channel is encrypted between devices and the Liho relay cannot read it. Access is “View only” or “Manage tasks”; actions outside the sandbox approved from a browser need an authenticator code.

Servers

Liho Server is designed for a single trusted owner: projects run under one service account with no isolation between them, and the server’s network is managed by its owner. In Liho Cloud, a workspace is a container on shared servers, and the cloud operator has access to its files.

Where tasks run

Liho IDE

Liho agent changes
In the chat the agent asks permission before every file edit and every command except a short list of read-only commands; access to .env files and keys needs a second confirmation. A turn’s changes can be kept or rolled back hunk by hunk. Automated tasks run in an isolated Git snapshot and reach the working tree after checks and applying. Commit, push and merge request are confirmed separately.
Third-party CLI agents
Claude Code, Codex and other CLIs work in the project directly, with their own permissions. The IDE manages their sessions but does not check their actions. OS-level restriction of CLI processes is available only on Linux.
Plugins and data for the agent
Each plugin runs in a separate process with the permissions declared in its manifest. Plugin data reaches the agent only through the IDE core: the HashiCorp Vault, S3 and Kafka tools return metadata, never secret values, changing tools need confirmation, and every agent action lands in the task journal.
Keys
Model provider keys are kept in the OS secure storage. When you ask for help with an error in the terminal, secrets are masked before sending.
Telemetry
Error reports and anonymous usage statistics are on by default. File contents, screenshots and variable values are not sent. Turn it off in the privacy settings or with the LIHO_TELEMETRY=0 variable.
Updates
The IDE checks for updates at launch and downloads them only with your consent.

Liho LLM

Request text
Under the privacy policy, the service does not store the text of requests and responses, only metadata: model, tokens, cost, time.
Model providers
Requests are processed by external model providers, which may store data under their own terms. Catalog models currently have no zero-data-retention mode.
API keys
A key’s secret is shown once; the service stores only its hash. A key can be restricted with a spending limit, a request limit and an expiration date, and revoked if it leaks.
Money
Amounts are stored as integers in millionths of a ruble, with no floating-point rounding. Each request is charged exactly once, for its actual usage.

Privacy policy

Report a vulnerability

A dedicated address for vulnerability reports has not been published yet. How to get in touch is described on the support page.

Support