SafetyCard Request a review

Mistral Vibe

Minimal CLI coding agent by Mistral

github.com/mistralai/mistral-vibe · 2026-10-03 · 7c19608

Defense-in-depth score

2.8 / 10

Vibe asks before running shell commands, fetching from new sites or calling MCP tools, and its command parser is unusually careful about hidden side effects. But the default profile writes and edits project files without asking, there is no sandbox, and unattended edits are not fully contained by the workspace-trust and approval controls. Avoid untrusted content in sessions that hold sensitive credentials.

Safest setup

Vibe asks before shell commands, new web origins and MCP calls, ignores a repository's project files until you trust the folder, and records every session in a full transcript. It has no sandbox and its default profile writes and edits files without asking, so the safest setup turns on approval for edits too and builds containment around the process.

SetupHowWhat it gives you
A scoped, low-limit environmentStart Vibe from a shell that exports only the keys this task needs, each scoped or read-only, with a spending limit on the Mistral keyCommands the agent runs reach only the accounts and spend you chose, not every credential in your shell C1
Approval for every call--agent ask, or default_agent set to ask in your user configFile writes and edits wait for your approval, alongside shell, network and MCP calls C2
The reviewed harness--legacy-harnessThe session stays on the reviewed Python harness and its approval rules, whatever a remote rollout selects C2
Only the tools needed--disabled-tools <name> for each tool the task has no use for, such as web fetch or searchThe model sees a smaller tool set, with network tools only when you want them C3
Trust after readingTrust a folder only after reading the files the trust prompt listsProject config, hooks, tools and instructions load only in folders you have chosen to trust C6
Limits for unattended runsRun unattended work with -p plus --max-turns <n> and --max-price <dollars>Each run stops at a turn and cost ceiling you set C10
Its own container or VMRun Vibe in a container or VM that mounts only the project and reaches only the hosts the task needsAn outer boundary around shell commands, hooks and extensions, which otherwise run on your host as you C4
The session transcriptKeep the default enabled = true under session_logging, and copy transcripts somewhere the agent can't writeA record of every tool call and result that outlives the session C9

Approving with confidence

  • Read each prompt and approve calls one at a time; an 'always allow' grant covers similar later commands, not only the exact one shown.
  • Approving a test runner or build command runs whatever the repository contains, so read what it will run first.
  • Once you approve a web origin, later requests to it run unattended.

Handling data

  • Transcripts under ~/.vibe/logs/session hold tool output unredacted; store them like the data the agent read.
  • Usage telemetry is on by default and carries metadata, not content; enable_telemetry = false turns it off.

Key gaps (2)

  1. No execution isolation: shell commands, hooks and extensions run on the host as the user with the full environment and network. C4 · Code-execution isolation
  2. Custom tool files are imported into the agent's own process, giving them its credentials and full environment. C7 · Third-party extensions

Criteria

C1 Identity & least privilege

0.13 / 1.00

Vibe runs as the local user with that user's full authority and does nothing to narrow it: every shell command inherits the complete process environment, including any provider API keys and cloud or Git credentials the user has exported. There is no per-tool identity or credential scoping; the only thing standing between a hijacked model and the user's accounts is the approval prompt on shell and network tools. The Mistral API key is kept in the OS keyring by default, which is good hygiene, but it is not a scoping control.

C2 Approval gates

0.25 / 1.00

Vibe has a careful approval system: shell commands are parsed with a real Bash grammar, compound commands are split and each part checked, dangerous options on otherwise read-only commands (find -exec, sort -o, git pager and config helpers) force a prompt, and the prompt shows the exact command. MCP tools, custom tools and sub-agent calls all pass through the same gate. However, the default agent profile auto-approves every file write and edit inside the project, so unattended edits are not fully contained by the approval and workspace-trust controls. An environment variable or config key also disables approval without a dedicated flag.

C3 Tool & action scoping

0.45 / 1.00

File tools resolve paths and check them against the workspace roots, prompt for anything outside, and treat .env files as sensitive; web_fetch approves per origin and refuses redirects to a different origin. But the central tool is a general shell that accepts any command string, there is no block on internal or metadata addresses, and the default tool set includes write, shell and network tools together. The model also chooses its own shell timeout with no upper bound.

C4 Code-execution isolation

0.00 / 1.00

There is no sandbox. Shell commands, hooks, custom Python tools and MCP servers all run directly on the host as the user, with the full environment and full network access. The approval prompt decides whether a command runs, but once it runs nothing contains it, and commands that look read-only (or a test runner the user approves) execute whatever the repository contains.

C5 Untrusted input blast radius

0.33 / 1.00

Content from web pages, repository files and MCP tool results enters the conversation with the same standing as the user's instructions; nothing tracks where content came from. What limits a hijacked agent is the general approval prompt: shell, web fetch to a new origin, web search and MCP calls all ask the user. File edits inside the project do not, and persistent agent configuration is not protected from unattended edits.

C6 Memory, context & configuration integrity

0.25 / 1.00

Vibe has a real workspace-trust step: project config, hooks, custom tools, skills, agents and AGENTS.md from a repository are ignored until the user trusts the folder, and the trust prompt lists the files it found. After that decision, however, project configuration is not integrity-protected, so poisoned project configuration can persist.

C7 Third-party extensions

0.07 / 1.00

Vibe loads three kinds of third-party code: MCP servers launched from config, custom Python tool files, and skills. None is pinned or integrity-checked. Custom tool files from the user's directory or a trusted project's .vibe/tools are imported straight into Vibe's own process at startup, with all its credentials. MCP stdio servers run as separate processes; the MCP SDK gives them a reduced default environment unless config supplies one. A trusted project can add any of these.

C8 Secrets & sensitive-data protection

0.40 / 1.00

The Mistral API key is stored in the OS keyring by default (falling back to ~/.vibe/.env), crash reports drop local variables and scrub paths, telemetry events carry metadata rather than prompt or tool content, and session transcripts are written owner-only. Reading .env files needs approval. But nothing redacts secrets from tool output before it goes to the model or into the transcript, the shell inherits the full environment (including any exported keys), and telemetry is on by default.

C9 Audit & traceability

0.50 / 1.00

Every session is recorded as a JSON-lines transcript of all messages, including each tool call and its result, under ~/.vibe/logs/session with owner-only permissions, flushed and fsynced after every model step. Sub-agent sessions are linked to the parent tool call. The record is outside the project folder, but the agent's shell could still edit it (with an outside-workdir approval), it is not tamper-evident, and approval decisions go to the log and telemetry rather than as structured fields in the transcript.

C10 Limits & kill switch

0.40 / 1.00

Turn, cost and token limits exist but only apply in programmatic (-p) mode; the default interactive session has no step, time or spend ceiling. Shell commands default to a 5-minute timeout, but the model can ask for any longer timeout. Stopping works well: Escape cancels the turn and running shell commands are killed with their whole process group. Sub-agents cannot spawn further sub-agents.