Why Libero — Libero

The useful version of an AI teammate is one with credentials. It reads the pull requests, checks the dashboard, files the ticket, triggers the deploy. The moment it can do those things, the interesting question stops being “how good is the model” and becomes “what happens when someone talks it into something.”

Prompt injection is not an edge case. Any channel member can type into the agent’s context, and so can the output of any tool it calls. Assume the model can be turned. Then ask what the agent is still unable to do.

If the answer depends on the system prompt, the answer is “nothing.”

The boundary is a process, not a paragraph

Libero splits into two services. The gateway and agent talks to Slack and runs the model loop. The tool proxy holds every credential and decides what each channel may do. They speak over mutual TLS on a private network, and the only thing that crosses is a tool call and its result.

Compromise the agent process completely and you get no credentials, only the tool surface that channel’s team sheet already allowed, and a log entry for every attempt. That is the whole design. Everything else is a consequence of it.

The rule is enforced in the code too: packages/agent may never import packages/proxy. An ESLint rule and a separate grep-level CI job both check it, because a boundary that only exists in a comment is not a boundary.

Enforcement belongs in a file you can review

Each channel has a team sheet: a TOML file in your git repo declaring which servers it may reach, which tools exist as far as it is concerned, which of those need a human click, what the daily budget is, and where traffic may go.

A tool that is not on the sheet is not in the definitions the agent receives, and a call to it is refused in the proxy regardless. Not discouraged. Refused, by a process that does not run the model.

There is no web admin UI, and there will not be one in v1. Permissions that matter deserve a diff, a reviewer, and a revert — which is to say they deserve to be files in a repo you already have.

One session per channel, not one per user

A per-user assistant learns things about a person. A per-channel teammate learns things about the work: what the team decided, what the runbook is, who owns the flaky test.

Channel membership is therefore the permission boundary, and it is a physical one — one SQLite file per channel, with no query path that can join across them. The agent addresses people by name because messages are stored with attribution, and the audit log records which human asked for each call. It never acts as any of them.

Self-hosted and model-agnostic, for the boring reasons

Your channel history, your curated memory, and your credentials stay on infrastructure you control, because that is what makes the credential boundary meaningful in the first place.

Models are swappable per channel — Anthropic, OpenAI, Google, Groq, Ollama, or anything behind an OpenAI-compatible endpoint. That is not neutrality for its own sake. A governed core that only works with one vendor’s model has an availability dependency in the middle of a security boundary.

MIT, proxy included

The entire core is MIT — the proxy is not held back as the paid tier. A security boundary nobody can read is a security boundary nobody can check. The governance document explains the CLA and the licence policy, including why AGPL and commercially-licensed dependencies are excluded from core.

What this costs

Honesty about the trade: Libero is slower to get features than a hosted product, it asks you to run two containers and write a TOML file per channel, and its roadmap deliberately parks anything that outpaces the proxy.