Safety Modes¶
The MCP server uses safety modes to control which tools are available. Each tool has a safety classification, and the server only exposes tools that match or are below the current mode.
Modes¶
Read-Only (Default)¶
Only tools classified as read are available. No resources can be created, modified, or deleted.
Use cases: Exploring infrastructure, answering questions, generating reports.
Non-Destructive¶
Tools classified as read and write (create/update) are available. Delete operations are blocked.
Use cases: Creating DNS records, deploying Helm charts, writing files.
Full Access¶
All tools are available, including destructive operations (delete resources, drain nodes, uninstall releases).
Use cases: Trusted automation, cleanup tasks, full infrastructure management.
Warning
Full access mode allows the AI to delete resources, remove DNS records, uninstall Helm releases, and drain Kubernetes nodes. Use only in controlled environments.
Confirmation-gated tools and --allow-destructive¶
A subset of write and destructive tools (deletes, key rotation) are tagged RequiresConfirmation. In the TUI and bnerd web, that field drives an interactive confirmation dialog; the MCP server has no dialog to show, so by default it hides these tools entirely — they simply do not appear in the tool list a client sees, even under --allow-writes. Pass --allow-destructive together with --allow-writes to expose them anyway. Doing so removes the human from the loop for that call: the MCP client becomes the only thing standing between the tool and execution, so use it only with a client and operator you trust to confirm destructive actions correctly on their own.
Safety Classification¶
Each tool is tagged with one of three safety levels:
| Level | Description | Examples |
|---|---|---|
| Read | Query/list operations, no side effects | list_dns_zones, kube_list_pods, fs_read_file |
| Write | Create or modify resources | create_dns_record, kube_scale, fs_write_file |
| Destructive | Delete or remove resources | delete_dns_record, kube_delete, helm_uninstall |
Destructive tools: the typed confirm echo¶
Every delete_* and revoke_* tool (and renew_rgw_key, which invalidates the key in use) takes a confirm parameter that must repeat the target id exactly. A call with a missing or mismatched confirm is refused before any request. On top of that the user is always asked to confirm in the chat or TUI dialog, which shows PERMANENTLY DELETE <kind> <id>. Destructive tools exist only in full mode; the default read-only mode and non-destructive mode never register them. On the MCP server specifically, these confirmation-gated tools are additionally hidden by default even under --allow-writes — see Confirmation-gated tools and --allow-destructive above.
Mode Compatibility¶
| Tool safety | read-only | non-destructive | allow-writes |
|---|---|---|---|
| Read | Yes | Yes | Yes |
| Write | No | Yes | Yes |
| Destructive | No | No | Yes |
Under the hood: modes are permission presets¶
--read-only, --non-destructive, and --allow-writes (and the shared --ai-mode equivalents used by the TUI and bnerd web) are built-in presets of bnerd's rule-based permission engine — the same engine that --ai-permissions profile files write custom rules against. A mode is nothing more than a canned allow/ask/deny rule list; there's no separate code path.
One consequence worth calling out: bnerd mcp-server has no interactive prompt to show, so an ask decision (the outcome for write tools under non-destructive and for write/destructive tools under full) resolves to execute rather than pausing — only deny actually blocks a call here. The MCP server's per-mode tool gating above already reflects that: non-destructive runs writes straight through, and full runs everything straight through. In the TUI and bnerd web, the same ask decision instead shows the interactive confirmation prompt.
See Permission Rules for the full rule engine, the preset tables, and how a --ai-permissions profile file overlays a mode's preset.
Audit Logging¶
All tool executions are logged to stderr with:
- Timestamp
- Tool name
- Safety level
- Parameters (sanitized)
This provides an audit trail of all operations performed through the MCP server.
Composing with --isolate¶
--isolate and --ai-mode (the same idea as --read-only/--non-destructive/--allow-writes for the MCP server) are orthogonal. They stack:
--ai-modecontrols which tools the AI can call.--isolatecontrols where the filesystem-touching tools can read or write.
# Most-restricted profile: read-only capabilities + filesystem-bounded + no kubeconfig
bnerd --isolate=strict --ai-mode read-only mcp-server
See the AI isolation guide for the full mount table and threat model.