How Centaur Enables a Secure, Unified Self‑Hosted AI Agent for the Whole Team

Why a Team‑Shared Agent Is Needed

Individual AI coding assistants run on each developer’s machine, leading to four major problems: duplicated configuration, scattered credentials, fragmented context, and no unified audit trail. Sharing a single agent that understands business logic and can access internal tools therefore becomes essential.

Centaur’s Core Idea

Centaur converts an AI agent from a personal desktop tool into a server‑deployed, team‑wide service that remains self‑hosted, isolated, and auditable. It is not a cloud SaaS offering; teams install it on their own machines or small servers.

Slack Integration

Users interact with Centaur via a Slack bot. When a message such as

@centaur 能查一下为什么 billing 的测试一直失败吗？

is posted, the system:

Creates an independent sandbox for the conversation.

Clones the relevant repository, runs commands, and invokes authorized tools inside the sandbox.

Streams progress and final answers back to the same Slack thread.

The bot therefore behaves like a teammate who can read code, execute commands, and query internal systems, but is reachable by every team member.

HTTP API

Centaur also exposes an HTTP API that lets programs create or reuse sessions, write user turns, start execution, and read events in a streaming fashion, enabling custom workflow integration.

Typical Use Cases

Diagnosing CI failures by running tests and inspecting logs in a sandbox.

Answering questions that require internal tool data, such as order status or service configuration.

Summarizing lengthy Slack discussions or customer contexts.

Running periodic health checks and generating reports.

Coordinating multi‑step operational workflows (e.g., check‑then‑run‑then‑summarize).

Providing every member with access to the same repository and test environment.

Standardizing tools, prompts, and agent personas across the team.

Technical Architecture

Centaur consists of three layers:

Ingress Layer : Slack bot and HTTP API handle incoming events.

Execution & Isolation Layer : Each session runs in an isolated Kubernetes sandbox containing shells, git, Python, Node.js, Bun, and other common dev tools. Any CLI‑based agent (Amp, Claude Code, Codex, etc.) can be mounted as a harness; Centaur only manages environment, tools, credentials, and state.

Controlled Egress : Sandboxes use a default‑deny network policy. Outbound traffic must pass through iron‑proxy , which only allows access to approved hosts and injects real credentials at request time, keeping the original API keys out of the sandbox.

All messages, execution steps, events, and delivery status are persisted in PostgreSQL, enabling replay, audit, and seamless reconnection after crashes.

Persistent Workflows for Long‑Running Tasks

Centaur introduces a Workflows mechanism: developers write Python functions where each ctx.step is a durable checkpoint. The workflow can pause, wait for external events, spawn sub‑agents, and survive service restarts.

WORKFLOW_NAME = "daily_digest"

async def handler(inp, ctx):
    data = await ctx.step("collect", lambda: collect_digest_data(inp))
    summary = await ctx.run_agent("summarize", text=f"Summarize this: {data}")
    return {"summary": summary}

The official guidance recommends using workflows when a task requires multiple requests, external conditions, scheduled execution, or coordinated agent rounds.

Tools and Permissions

Agents gain capabilities through small Python plugins placed under tools/my_tool/ with a standard layout ( __init__.py, client.py, cli.py, .env.example, pyproject.toml). The .env.example file declares required environment variables (credentials). When a sandbox starts, the tool is installed as a local CLI command, visible via centaur-tools list. The principle is “add once, use everywhere”: a single tool implementation becomes available to all agent sessions.

Self‑Hosted Deployment

Although Centaur is self‑hosted, it does not require a full production‑grade Kubernetes cluster. A lightweight k3s cluster on a small VPS, DigitalOcean droplet, Linux box, or macOS machine suffices.

# Clone the repository and install the local command runner
git clone ... && cd centaur
brew install just

# Bootstrap secrets (Slack token, signing key, 1Password token) and start
just bootstrap-secrets
just up

After the initial run, the bot can be invoked from Slack. The documentation also provides a “Mac Mini style” guide for deploying k3s on a small server.

Comparison with Alternatives

Personal Local Agent : No sharing, credentials scattered, no isolation, low cost, suitable only for solo projects.

Cloud‑Hosted Agent Platforms : Provide sharing but rely on third‑party data handling, limited control over isolation, usage‑based pricing.

Centaur (Self‑Hosted) : Offers team‑wide sharing, credential injection via iron‑proxy, per‑session Kubernetes sandbox with default‑deny networking, higher operational cost but full data sovereignty and auditability.

Centaur occupies the middle ground, delivering cloud‑like sharing and governance while retaining self‑hosted control.

Limitations and Risks

High entry barrier: requires Kubernetes knowledge, Slack app configuration, and 1Password management.

Infrastructure dependency: a continuously running machine for k3s is mandatory.

Credential service dependency: iron‑proxy relies on a maintained 1Password environment.

License uncertainty: the repository’s LICENSE field is NOASSERTION, so commercial use must verify permissions.

Best suited for team‑shared scenarios; individual users may find it heavyweight.

Design Takeaways

Isolation should grant minimal necessary capabilities, not just “lock down”.

Never expose raw credentials to the runtime; inject them only at the point of use via a proxy.

Decouple platform concerns (environment, tools, credentials, state, audit) from the agent framework itself.

Persist state for replayable audit trails rather than adding audit as an after‑thought.

Use persistent, checkpointed workflows to turn one‑off calls into reliable, long‑running processes.

Conclusion

Centaur answers the practical question of how a team can share a secure, business‑aware AI agent: it provides a self‑hosted platform with isolated sandboxes, controlled egress, credential injection, and persistent workflows, delivering cloud‑like sharing and governance while keeping data under the team’s control.