Security

An agent runs commands on a real machine. The question is not whether you trust it, but what happens the one time it gets something wrong. This page describes what limits it.

Trust profile

A trust profile is a set of rules defining what an agent may do on its own, what needs approval, and what it may not do at all. A profile is defined at the organisation level and assigned to a project.

There are three built-in profiles:

Your own profiles are built from these: a list of what is allowed, a list of what is forbidden, and a list of what requires approval. Custom profiles are available from the Company plan up — the three system ones work on every plan, the free one included: safety does not switch off with the payment.

Stop patterns

Separately from profiles there are rules that stop a command by its shape. They exist precisely because a "dangerous command" rarely looks obvious.

What is covered specifically, rather than in general:

• deleting at the root — rm -rf / and its variants with globs;
• going around it with sudo — sudo rm -rf / does not get safer for starting with a different word;
• going around it with ssh — ssh host 'rm -rf /' runs elsewhere, but it runs;
• going around it with docker exec — a command inside a container is still a command;
• disk operations, edits to system settings, powering the machine off.

The parsing follows the meaning of the command, not a substring: a command with a harmless beginning and a dangerous continuation does not get through.

Testing the rules before you need them

The profile editor has a field where you can type a command and see what would happen to it: allowed, forbidden, or requiring approval.

Use it while writing your own profile. Testing your rules on a real task is a poor way to discover a typo in them.

Protected paths

Separately, you set paths the agent may not touch even when the command itself is allowed: directories with keys, system settings, whatever you decide.

The command log

Every command an agent runs is recorded: what was executed, in which task, by which agent, and how it ended.

The log is visible on the project's "Commands" screen and on a tab inside the task. There are filters, a live tail and a CSV export.

Three properties worth knowing:

• Secrets are masked. Tokens and keys inside commands are replaced with a marker — the log does not become the place where they leak.
• Entries cannot be changed or deleted. That is not a promise made in the interface but a restriction at the level of database privileges: the application physically has no right to update or delete log rows. Even a bug in the platform's code will not rewrite history.
• The plan limits how far back you can look, not how long we keep it. Lower plans show the recent weeks, higher ones show everything. Every entry is kept regardless: as said above, the platform physically cannot delete them. Move to a higher plan and the earlier history is there.

What the platform knows about your code

The client never sends the contents of your project files to the server — only names, paths and commands. This is not a setting you can switch on: the client has no upload code for file contents at all, and that absence is the guarantee.

There is a direct consequence for project documents. A specification often lives in the repository itself — docs/SPEC.md next to the code, versioned with it. Such a document is added by path: in the "Add document" dialog pick "Path in repository" and type docs/SPEC.md.

The platform stores the address, not the text. The agent receives the same path and opens the file on its own machine — it is already on disk there. Such a document cannot be downloaded through the platform: there is nothing to download.

If the contents must be visible in the browser — to people who do not have the repository — the two earlier ways remain: text written in the platform and an uploaded file. The choice is yours, and it is a deliberate one: visibility in exchange for a copy.

What stays on your side

Plainly about the limits:

• The agent works with the privileges of whoever started it. If that person has access to the production server, so does the agent on their machine. The platform restricts commands; it does not rewrite operating-system permissions.
• A profile protects against a mistake, not against ill intent. The person who started the agent can run the same commands by hand — the log will see it, but it will not stop them.
• The keys stay with you. The platform does not store your SSH keys or your server access tokens.