obot-platform/obot

Obot – Platform for Governing Enterprise AI

What it is

• An open‑source platform that lets an organization run a private “AI hub”. It sits between AI‑enabled tools (VS Code, Claude Code, Cursor, etc.) and the large‑language‑model (LLM) or tool‑calling services those tools use.
• Its goal is governance: control who can call which model or tool, keep credentials central, audit every request, and optionally host custom tool‑servers (MCP servers) in a sandbox.

Key pieces

Component	Role
Obot Server	Core service exposing two gateways (MCP and LLM), identity & access control, audit logging, and registries for tool‑servers (MCP) and “skills”.
MCP Gateway	A single, policy‑enforced entry point for any Model‑Calling‑Protocol server – the generic API many AI‑agents use to run external tools.
LLM Gateway	Provider‑agnostic endpoint that forwards calls to OpenAI, Anthropic, Bedrock, Azure, etc., while storing the API keys centrally and applying per‑user model‑access policies.
Sandboxed MCP Servers / Agents	Ability to spin up tool‑servers (e.g., npx, uvx, Docker containers) inside isolated containers or Kubernetes pods, with network‑policy egress controls.
MCP & Skills Registries	Git‑backed catalogs that list available tool‑servers and reusable “skills” (pre‑packaged agent capabilities).
Obot CLI & Skill	Command‑line client for discovering/installing approved servers and skills; a “skill” that lets an AI agent invoke the CLI itself.
Obot Sentry	Optional device‑side agent that inventories installed AI clients, injects hooks into IDEs, and records local tool calls, extending audit coverage to the user’s workstation.
Identity & Access Control	Integration with external IdPs (e.g., SSO), role‑based permissions, scoped API keys, and secret management.
Audit Logs	Correlated logs of MCP calls, LLM requests, token usage, model cost, and device‑side activity, filterable by many dimensions and exportable.

How you would use it

1. Deploy the server (Docker for a quick demo, Kubernetes for production). The Docker command in the README spins up the service, mounts the host Docker socket so the platform can launch sandboxed tool containers, and creates a bootstrap token for first‑time login.
2. Connect an identity provider (Okta, Azure AD, etc.) so users authenticate with corporate credentials.
3. Register model providers (OpenAI, Anthropic, etc.) and define Model Access Policies that say which users or groups may call which models.
4. Add MCP servers or skills to the Git‑backed catalog, optionally hosting them inside the platform.
5. Install the Obot CLI on a workstation; the CLI can pull approved MCP servers/skills and expose them to local AI clients.
6. Deploy Obot Sentry on managed devices to capture IDE‑side tool calls (e.g., Claude Code, VS Code extensions) and enforce device‑level policies.
7. Monitor everything through the built‑in audit UI or export logs for SIEM integration.

Why it matters

• Security & compliance: Central credential storage, per‑user model restrictions, and audit trails help enterprises meet governance requirements for AI usage.
• Vendor lock‑in avoidance: Organizations can mix‑and‑match model providers and tool servers without forcing a single client stack.
• Extensibility: The MCP abstraction lets you plug in any tool‑calling service, and the skill registry encourages reusable agent capabilities.

Where to learn more

• Full docs: https://docs.obot.ai
• Design proposals & ADRs are kept in the repo for deeper architectural insight.
• Community chat on Discord (link in README).

License: MIT, so you can run, modify, and embed the platform in commercial environments.