DOCSEARCHbyAlgolia
Submit Docs

Obot Platform Documentation

repository·main·Indexed 18 days ago

https://github.com/obot-platform/obot

An open-source platform for managing, securing, and governing AI ecosystems. Obot provides shared infrastructure including an MCP Gateway for tool access control, an LLM Gateway for provider-compatible model endpoints, and Obot Sentry for monitoring AI activity on local devices. It features sandboxed execution for MCP servers and agents, centralized MCP and Skills Registries, and a dedicated CLI for resource discovery and management.

Tokens
83.4K
Snippets
183
Records
379
Agent score
75%

What's inside Obot

  1. Overview of Obot Agent Management capabilities

    main

    Once enabled, the Obot Agent Management admin area provides several tools for monitoring and controlling agent behavior:

    • Token Usage: Monitor costs and optimization opportunities by viewing token usage across different users and models.
    • Model Providers: Configure LLM providers and their specific available models.
    • Model Access Policies: Define which users and groups are permitted to access specific models.
    • Message Policies: Enforce content rules on user prompts and tool calls using natural language instructions.
    • Message Policy Violations: Review metadata for blocked content, trends, and specific policy violations.

  3. Monitor device inventory and scan coverage

    main

    Administrators can use several views under Device Management to monitor the organization:

    • Overview: Dashboard for scan coverage, top clients/MCP servers/skills, and submission activity trends.
    • Devices: List of workstations that have submitted scans. Provides high-level inventory counts and links to device history/detail pages.
    • Device Skills: Inventory of observed skills across the fleet with drilldowns to specific devices.
    • Device MCP Servers: Inventory of observed MCP servers with drilldowns to affected devices and client configurations.
    • Device Clients: Inventory of observed AI clients with drilldowns to associated users, MCP servers, and skills.

  4. Understand Device Client Inventory and Details

    main

    Obot provides a Client inventory view that groups observed AI clients by name. Administrators can use this view to search, sort (by name, MCP server count, skill count, or user count), and drill down into client details.

    Client Detail Page: Shows users whose latest device scans include that client, along with associated MCP servers and skills.

    Scan Item Details: When opening specific items from a device or scan page, you can view scan-scoped details:

    • MCP server details: Includes client/scope, endpoint or command, related configuration file, and a reconstructed configuration snippet (secrets are masked with placeholders).
    • Skill details: Includes client/scope, description, source information, parent plugin, and supporting files (including file content if available).
    • Plugin details: Includes client/scope, metadata, enabled state, detected capabilities, and supporting files.

  5. Compare Obot Editions

    main

    Obot is available in three editions, all delivered via the same container image. You can upgrade between editions directly within the application. The editions differ by enabled capabilities and usage limits:

    EditionUser/Device LimitKey Features
    ObotUp to 100 users & 100 devicesDefault edition; standard authentication.
    Obot CommunityUp to 100 users & 100 devicesAdds enterprise-grade auth providers (Entra, Okta, JumpCloud, Auth0).
    Obot EnterpriseUnlimited users & devicesEverything in Community plus enterprise support.

    Note: Obot Community is free and requires a one-time registration.

  6. What is included in a Device Scan submission

    main

    When a device scan is submitted, it includes the following data points:

    • Device metadata: Hostname, OS, architecture, OS username, scanner version, scan time, and stable device identity.
    • AI clients: Detected clients and their local install or configuration paths.
    • MCP server observations: Location of the server and the command or URL used to launch it. Note: Environment variable values and HTTP header values are not recorded; only their key names are captured.
    • Skill observations: Metadata, related files, script presence, and source information.
    • Plugin observations: Metadata, enabled state, related files, and detected capabilities.
    • Captured files: Config or manifest files.

    :::caution Captured config and manifest file content may contain whatever is present in those files. Files larger than 1 MiB are recorded as oversized and their content is not included. :::

  7. What is a Skill in Obot?

    main

    A Skill is a reusable, structured package of instructions that agents can discover and install to expand their capabilities. Skills follow the Agent Skills standard.

    Skill Structure

    A skill is defined as a directory within a GitHub repository containing a SKILL.md file. When an agent installs a skill, the entire directory is downloaded, allowing the skill to include supporting files like helper scripts or reference data.

    SKILL.md Format

    The SKILL.md file must use YAML frontmatter to define metadata, followed by Markdown content for the instructions. The metadata includes:

    • Name: A unique identifier within the repository (e.g., code-review).
    • Display Name: A human-readable name (e.g., Code Review).
    • Description: A summary of the skill's purpose.
    • License: The skill's license type.
    • Compatibility: Requirements or constraints (e.g., Python 3.8+).

  8. Overview of the Obot LLM Gateway

    main

    The Obot LLM Gateway acts as a proxy for multiple LLM providers (OpenAI, Anthropic, Generic Responses Compatible, Amazon Bedrock, and Azure). It allows you to use an Obot API key instead of managing individual provider credentials.

    Key Benefits

    • Credential Security: You never handle the provider's real API keys; Obot manages them centrally.
    • Access Control: Access is governed by Model Access Policies, ensuring you only call models explicitly granted to you.
    • Scoped Discovery: The /v1/models endpoint only returns models you are authorized to use.

    Supported Providers and Base URLs

    To use the gateway, point your Mantle-compatible client (like Claude Code or Codex) to the appropriate endpoint:

    ProviderBase URLAuthentication Type
    OpenAIhttps://<your-obot-host>/api/llm-proxy/openaiObot API Key
    Anthropichttps://<your-obot-host>/api/llm-proxy/anthropicObot API Key
    Generic Responses Compatiblehttps://<your-obot-host>/api/llm-proxy/generic-responsesObot API Key
    Amazon Bedrock/api/llm-proxy/aws-bedrockStatic credentials
    Amazon Bedrock/api/llm-proxy/aws-bedrock-api-keyAPI key
    Azure/api/llm-proxy/azureAPI key
    Azure Entra/api/llm-proxy/azure-entraEntra auth

    Note: For Bedrock and Azure, the gateway detects the request format from the requested /messages or /responses endpoint.

  9. Configure Kubernetes image pull secrets for MCP servers

    main

    When running MCP servers in Kubernetes, you can attach image pull secrets to their Deployments to allow pulling images from private registries (e.g., GHCR, Docker Hub, Amazon ECR).

    There are two mutually exclusive configuration methods:

    1. Static Helm pull secrets: Managed via Helm values. Use this if you want credentials managed by external tools like GitOps or an external secret controller.
    2. Managed image pull secrets: Managed via the Obot admin UI. Obot handles the creation of Kubernetes kubernetes.io/dockerconfigjson secrets and automatically attaches them to MCP server Deployments.

    Note: If static mcpImagePullSecrets are configured, the managed image pull secrets UI and API become read-only. To switch back to managed secrets, remove the Helm value and restart Obot.

  10. How MCP Tunnels work

    main

    MCP tunnels allow the Obot gateway to reach remote HTTP or HTTPS MCP servers located on private networks that are not directly accessible from the Obot network.

    An obot tunnel process runs on a machine that can reach both Obot and the private MCP server. It opens an outbound, authenticated WebSocket connection to Obot. Traffic flows as follows:

    1. The Obot gateway receives a request for a remote MCP server.
    2. The remote MCP catalog entry selects an MCP tunnel by its generated ID.
    3. Obot sends the HTTP request over the WebSocket tunnel.
    4. The obot tunnel process forwards the request to the real MCP server URL and returns its response.

    Note: MCP tunnels proxy HTTP requests and streaming responses; they are not general-purpose TCP tunnels or VPNs.

  11. How Agents Use Skills

    main

    Agents interact with skills through a lifecycle of discovery, installation, and execution.

    Agent Capabilities

    • Search skills: Agents search the catalog for matching queries. Access is governed by Skill Access Policies.
    • Install a skill: Agents download skills from the catalog. If a skill with the same name is already installed, the agent will prompt for confirmation before overwriting it.
    • List installed skills: Agents can view all currently available skills (both built-in and user-installed).
    • Use a skill: Once installed, the agent reads and follows the instructions provided in the skill's SKILL.md during a conversation.

    Installation Scope

    Skills are installed at the agent level, meaning once a skill is installed, it remains available for all future conversation threads for that agent.

    Built-in Skills

    Obot includes a set of built-in skills (e.g., workflow management, Python scripting) that are always available without requiring manual installation.

  12. How Model Access Policies work

    main

    Model Access Policies in Obot Agent control which users and groups can use specific language models. Each policy is composed of two primary components:

    1. Who (Subjects): The entities granted access. This can be:

      • Individual users: Specific people selected by name.
      • Groups: Authentication provider groups (e.g., "engineering", "marketing").
      • Everyone: Using the "All Obot Users" option to grant access to all authenticated users.

    2. Which (Models): The models granted to the subjects. This can include:

      • Specific models: Individual models from configured providers.
      • Default model aliases: Dynamic references to the current default models (e.g., Language Model (Chat) or Language Model (Chat - Fast)).
      • Wildcard suffix patterns: Prefix-based matching (e.g., claude-haiku-4-5*).
      • All models: A catch-all for every available model.

    Note for Administrators: Administrators do not have automatic access to all models. They must be explicitly included in a policy to use models in chat.