# What Libero is > A self-hosted, LLM-agnostic AI teammate that lives in Slack channels as a shared agent, with admin-governed tool access and an append-only audit log. Source: https://getlibero.com/docs/ · Libero v0.7.0 · pre-1.0 --- Libero is a self-hostable, LLM-agnostic AI teammate that lives in Slack channels as a shared agent — one session per channel, not per user — with persistent curated memory, admin-governed tool access, and asynchronous task execution. The design principle everything else follows from: **the agent is visibly not a user.** It acts only as itself, under admin-provisioned service credentials, through an allowlisted proxy, with every action audited. Channel isolation is a hard admin-defined boundary enforced in code, never model self-restraint. > **Pre-1.0** > > `v0.7.0` is current, and these pages describe what runs. What pre-1.0 means in practice: the > team-sheet format can still change between releases — the [changelog](https://getlibero.com/docs/changelog.md) says > when — and certificate rotation is two commands with a human edit between them rather than > anything automated. [Self-hosting](https://getlibero.com/docs/self-hosting.md) is where to start, and it says to start in > a scratch workspace. The governed core is shipped and attacked by its own end-to-end suite: mutual TLS, per-channel identity taken from the client certificate, team-sheet enforcement on both gates, the vault, credential injection and redaction, the MCP client and its pool, OAuth for upstreams that want it, daily caps in both calls and dollars, the hash-chained audit log, and the approval broker with its Slack card. Built on it: curated memory and semantic recall, skills and their lifecycle, ambient mode — the heartbeat, proactive posts behind a rate window, and `schedule_task` — and, as of `v0.4.0`, code execution in an ephemeral container whose only way out is the channel's `[egress]` allowlist. As of `v0.5.0` the skill library has two halves: the playbooks a channel grows for itself, and the ones an operator publishes once — named per channel in the team sheet, mounted read-only, and never touched by the model. As of `v0.6.0` recurrence lives in the team sheet: an `[[ambient.rule]]` entry fires a turn at a clock time, in a named timezone, on the days it lists — authored by the operator, so a prompt-injected model cannot plant one. As of `v0.7.0` the deployment chooses how it reaches a model — directly, through a LiteLLM you already run, or through the sidecar the compose file can start — and where credentials live at rest: two encrypted files by default, or Google Secret Manager or AWS Secrets Manager behind one variable. `npx @getlibero/cli init` through `docker compose up` stands the stack up from a clean checkout. The [roadmap](https://getlibero.com/docs/roadmap.md) is the record of how it got here and where a release landed differently from its own plan. ## The shape of it Two deployable services plus per-channel state. The **gateway and agent** connects to Slack over Socket Mode, routes each `(workspace, channel)` pair to a shared session, and runs a provider-agnostic agent loop. The **tool proxy** holds every tool credential, enforces each channel's team sheet, brokers human approvals, meters spend, and writes the audit log. The security property the whole design hangs on: tool credentials live only in the proxy, and the agent reaches tools only through it. Compromise of the agent process — prompt injection, a malicious skill, a misbehaving model — yields no tool credentials and only the tool surface that channel's team sheet allows, with every call audited. The agent process holds the Slack tokens and the model provider key, because the gateway and the loop cannot run without them; neither reaches a tool the proxy guards. The [security model](https://getlibero.com/docs/security.md#which-secrets-are-where) has the full account. ## What an admin actually configures One TOML file per channel, kept in your own git repo. It declares which MCP servers the channel may reach, which tools on them exist as far as that channel is concerned, which of those need a human click, and what the daily budget is. An `[egress]` block says where sandboxed code may reach, and no block means nowhere. Nothing in it is a secret — credentials appear as names, resolved only inside the proxy's vault. There is no web admin UI in v1, and that is a decision rather than an omission: the files in git *are* the admin surface. - [Architecture](https://getlibero.com/docs/architecture.md) — The two services, the agent loop, the proxy's five jobs, memory, skills, and the sandbox. - [Team sheets](https://getlibero.com/docs/team-sheet.md) — The per-channel manifest: allowlists, approvals, budgets, egress. - [Security model](https://getlibero.com/docs/security.md) — The threat model, the mitigations in priority order, and what is out of scope. - [Self-hosting](https://getlibero.com/docs/self-hosting.md) — Start here to run it: the four commands that stand a deployment up, and an honest account of what does not work yet. ## Why "libero" In football, the libero is the free player — the one who sweeps up behind the team, covering whatever gets through. That is the job here: an AI teammate in your Slack channels that handles the work nobody is on, under rules your admins write. And like the libero in volleyball — the specialist who plays under explicit restrictions, marked by a different jersey — this agent is visibly *not* a user: it acts only as itself, only through an allowlisted tool proxy, with every action audited. Free player, firm rules.