Self-hosted AI agents, in production · installs in fifteen minutes
Rikoo

Everything an agent can be plugged into.

Rikoo speaks the Model Context Protocol. Three servers ship inside the product and run in a sandbox created for one run; any other server you or a vendor operates is declared once and granted tool by tool.

Embedded

Three servers that need no declaration.

They are off by default. Turned on, they run inside a workspace created for one run and destroyed with it, under a dedicated system identity, with no access to the host and no path into another run.

  • Files

    Read, write and list inside the run workspace. Nothing outside it is reachable, and the workspace goes away when the run ends.

  • Shell

    Run a command inside the sandbox. It has no network at all, which is the point: it manipulates what the run already has rather than fetching more.

  • Browser

    Open a page and read it. Its traffic leaves through the same anti-SSRF guard as everything else, so it cannot be pointed at your internal network.

Remote servers

Connect what your teams already use.

Any MCP server reachable over HTTP, SSE or Streamable can be declared at the project level. These are the ones teams connect first; the list is not a limit.

  • GitHub

    Issues, pull requests, code search. Connected over OAuth 2.1, with the tokens sealed in the vault and refreshed without anyone re-authorising.

  • Notion and Confluence

    Read pages and databases as tools, or ingest them as knowledge through the source connectors in Enterprise.

  • Linear and Jira

    Read and create issues. Write tools can be withheld from an agent that only needs to look, or marked as requiring human approval.

  • Your database

    A read-only MCP server over PostgreSQL is a common first tool. The credential lives in the vault and never reaches the model.

  • PagerDuty and your on-call stack

    The operations use case: an agent that can look at an incident, and act on it only behind an approval.

  • Your own server

    Describe your internal API as an MCP server, or declare project HTTP tools in JSON Schema authenticated by a vault secret.

How access is decided

Granting a server does not grant everything on it.

Each tool is allowed individually. A tool that writes can be withheld from an agent that only needs to read, and any tool can be marked as requiring a human decision before it runs.

The restriction is enforced when the call is made, on the server side. Hiding a tool from the model is a usability choice; refusing the call is the security control.

  • A server has to be explicitly allowed to return images, per server
  • A circuit breaker and a health probe per server, so one bad dependency does not stall a run
  • Large outputs offloaded to object storage and re-read on demand
  • Everything a tool returns is framed as untrusted content before it reaches the model

Tools and MCP servers

Connect one in about five minutes.

Declare the server, allow the tools you want, grant it to an agent, try it in the playground.