Security

In plain words: what lives where, and what bots can reach.

What lives where

WhereHolds
The Tico serverTeam data: humans, tasks, conversations, docs, files, and encrypted Credentials. The server decrypts and delivers granted Credentials, including model keys granted to Every computer. It runs no bots.
Your computersComputer-local model subscription logins, bot repos, and Credentials delivered for bot runs. Bots use Tico with their own access rights.

Protections

One computer, one trust boundary

In the supported Docker runner, bots run as their own bot user and can’t read the runner’s own login. Bots on the same computer still share that user, so they can reach each other’s files and model logins. That’s by design. Use separate computers for unrelated trust domains. Native Mac and legacy runners share the supervisor’s user. Store new Tool Credentials in Tools → Credentials and grant them to the bot; declaring a Tool alone grants no Credential. Existing installs keep migrated access. See Credential storage and backups.

Example

Your message bot reads outside email, which anyone can send. Run it on a different computer from your finance bot, and keep team-wide credentials, like a Google service account, off the message bot’s computer.

A tradeoff we chose

The one-click updater can control Docker on the server, which is powerful. Only the server runs there, and no bots. If you’d rather not allow it, turn the updater off and update by hand.

On AWS

Set the instance metadata hop limit to 1 on the server and on every computer, so containers can’t read the instance’s role.

Anonymous install count

To count how many Tico installs are in use, Tico sends four things with its update check, about every six hours:

Nothing else: no team name, emails, humans, bot names, counts, or content, and no IP addresses are stored. You see a notice before anything is sent, and the totals are published openly.

To turn it off, use any one of these:

Details are in PRIVACY.md.

Who can see and use each bot

Every bot has three kinds of access, for humans, groups, and other bots:

AccessLets you
SeeFind it on the team chart and in bot lists.
ReadRead its work: tasks, updates, files, and status.
WriteMessage it and give it work.

Bots start Open. Pick a preset in Settings → Bots → Access: Open, Visible, requests only, or Private. The team chart can filter to just the bots you can read or write to.

Example

Set your Legal bot to Visible, requests only. Everyone can find it and send it a question, but only the legal team can read its work.

Roles

RoleCan
OwnerEverything.
AdminManage every bot except the Built-in ones, plus humans and computers.
MemberCreate and manage their own bots (up to 25 active by default), add teammates, and use the bots they’re allowed to.

New computers accept members’ bots. To keep a computer for your own bots and credentials, turn off Accepts members’ bots for it in Settings → Computers.

Ask BotOps

Tell BotOps what you want, like “build me a Jira bot,” “let Ana see it,” or “tell me issues to solve.” It does what you could do in the app, as you, and a member can’t get it to do what only an owner may. It finishes the job, then tells you what it did.

BotOps changes your Team rules directly when asked, with your rights. You can ask it to add humans outside your team’s domain, update Tico, or delete bots and their repositories. Bots draft messages to outsiders until sending is turned on for each bot.

Credentials in chat

Report a problem

Use private vulnerability reporting on GitHub.