How AI agents are kept safe

Who this is for: admins and security reviewers who want to know what an AI assistant can and can’t do in Liitora.

Before you start: it helps to read How Liitora keeps you safe first.

An AI assistant is fast and helpful, but it can make mistakes, and someone could try to trick it. Liitora is built so that neither leads to harm: the assistant does the work, people keep the keys and the final say.

It only makes drafts

Everything an assistant saves is a new version of a workflow. Versions never change after they are saved, and a new workflow starts as a Draft. A draft doesn’t run on its own. The assistant can test it and try it with a test run, which uses your test connections. A test run never gets your production addresses or credentials, see Test and production settings.

Until a person approves a version, its test runs and dry runs are limited. A script gets a real secret value only if the workflow’s last approved version also reads that secret. Its own web requests reach only the hosts of the connections it declares, and it sends no email. So a draft can’t read a secret no one agreed to, or send data to a place no connection points at. See Before a person approves the version.

A person approves

By default a workflow’s activation policy is A person approves each version. The assistant can’t approve; there is no tool for it.
An assistant never approves, not even when it signs in as a person. What it writes counts as the assistant’s work, so a person reviews it before it runs. That person may be the one the assistant worked for.
Only admins can approve. The approval is for one exact version: any change makes a new version that needs a new approval.
An admin may switch a workflow to The AI assistant may activate tested versions. Only a person can change this policy.

Tests must pass first

Every workflow has test cases that run on each save, against fake answers, so nothing real is touched. A version can only be activated when every case passes on that exact version and the required minimum is met: a normal case, and where it matters a case for a failing upstream system, an empty case and a malformed webhook payload. The tests also show you in plain sentences what the workflow does. See Read and write workflow tests.

Secrets never reach the assistant

The assistant asks for a secret by name with a reason. You add the value on a Liitora page through a fill link. The value never passes through the chat.
The assistant sees only names and statuses (Requested, Set, Expired). No tool can show, set, rotate or delete a value.
Connections hold secret names, never values. Scripts read secrets by name while they run, and Liitora removes the values from everything the assistant can read: logs, outputs and errors.
Webhook signing secrets are made by Liitora and shown only to people with the Reveal secrets permission.

Credentials in code are refused

Liitora scans what the assistant writes: scripts, with: values and test data. A password, API key, private key or token written into them (for example an sk- key, a JWT or Bearer followed by a token) is an error for AI authors, and the save is refused with a hint to use a secret instead. Test data must use obvious dummy values.

A last guard checks every tool result before the assistant gets it and masks anything that looks like a credential.

It stays in its lane

The assistant acts for one company only, and only with its permissions. The AI assistant role can build, test and run workflows, manage webhooks and connections, and read runs. It can’t approve, manage secrets, members, API tokens or billing, or read the audit log.
Scripts run in the sandbox and can only call public HTTPS addresses, so a workflow can’t reach your internal network or our servers.

Everything is recorded

Every change the assistant makes is in the audit log, marked as made by an AI assistant or an API token. Each version shows who made it.