# Derbent [Health: Active]

**Category:** 💻 Developer Tools  
**Repository:** https://github.com/tunahanaliozturk/derbent  
**GitHub Stars:** 1  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/derbent

## Description
Gate for coding agents' MCP and built-in tool calls: rules, approvals and hash-chained receipts

## Claude Desktop Quick Installation
No confirmed install details yet, so no config is published. Follow the setup steps in the repository above.

## Documentation

## What Derbent MCP server does

The Derbent MCP server acts as a controlled gateway for coding-agent tool calls. It covers both MCP tools and selected built-in CLI tools, such as shell commands and file edits, by applying one policy model before execution. Downstream MCP servers can sit behind Derbent, allowing an agent to use one Derbent MCP entry rather than configuring the gate separately for every downstream server.

Rules can allow, deny, or ask for a decision based on the agent, tool name, and arguments. Rules are evaluated in order, and the first match determines the initial result. Repository-level rules can make the global policy stricter. Budgets can stop an agent that is repeatedly calling tools, while pins can hold back a downstream tool when its definition changes.

Calls that require approval wait in the terminal UI or can be handled with approval commands from another shell. Shared memory and handoffs let agents keep repository notes and leave work for one another.

## How it works

Each tool call is recorded as a receipt in SQLite. Receipts form a hash chain, and `derbent verify` checks the chain and identifies the first broken receipt if an entry was changed, moved, inserted, or removed. Arguments are stored after secret masking; tool results are represented by their size and hash. To detect deletion of the newest entries, keep the reported head hash outside the database.

The `derbent mcp --agent <name>` command is the MCP endpoint used by an agent. The `derbent gate --agent <name>` command serves as the pre-tool hook for built-in tools. The terminal UI displays waiting calls, agents, receipts, memory, and grants. `derbent explain` shows how a proposed call matches rules, project restrictions, budgets, pins, and grants before the call occurs.

Derbent uses one SQLite file as shared state. It does not run a daemon and does not open a network listener. The project describes it as a guard against mistakes and prompt injection, not as a sandbox; a process that already has permission to execute shell commands can bypass it.

## Setup and configuration

Install a release binary for Windows, macOS, or Linux, verify it with the published `SHA256SUMS`, and place `derbent` on `PATH`. The project also supports installation with Go 1.27 or later, Homebrew, and Scoop.

Run `derbent init --preset balanced` to add Derbent to detected CLIs and create an initial configuration. Initialization displays its changes, asks for confirmation, backs up files it modifies, and preserves existing entries. Use `--dry-run` to preview changes, then run `derbent doctor` to check the resulting setup. The configuration file is stored in the platform’s user configuration directory.

The documented CLI connections include Claude Code, Codex, GitHub Copilot CLI, and Antigravity CLI. Codex and Antigravity support is experimental. Project-specific MCP servers are configured behind Derbent according to the downstream-server setup instructions.

## Tools and capabilities

- Configure allow, deny, and approval rules with tool and argument matching.
- Approve or deny pending calls from the terminal UI or shell commands.
- Inspect decisions with `explain` and review calls with `receipts`.
- Verify the receipt chain and export records for checking outside the database.
- Manage session grants and revoke them when needed.
- Store repository memory and agent handoffs.
- Apply budgets and pins to downstream tool use.

## Limitations and notes

Derbent is a policy gate and audit mechanism, not a sandbox. Its receipts are tamper-evident rather than immutable: someone who can write the SQLite database could rewrite the chain or remove recent records. Keeping the head hash elsewhere is required to detect deletion of the newest receipts. Built-in-tool coverage depends on the hook support provided by each CLI, and Codex and Antigravity integration has not yet been checked in a real session.

_Full upstream README: https://allmcps.com/mcp/derbent/readme_