Security.
MeshConsole runs coding agents that execute real commands and edit real files. That only works if the boundaries are explicit — what stays local, where secrets live, and what an agent is allowed to do without you.
Local-first by construction
Your source files, terminal sessions, editor buffers, workspace layouts, and MeshMemory notes stay on your own disk. Agents run as local processes against local folders. There is no server-side copy of your repository, and nothing indexes your codebase remotely.
Hosted surfaces are the exception and are named as such: your account and entitlements, the credit ledger, and anything you deliberately sync through the hosted MeshMCP endpoint.
Where secrets live
- SSH passwords and key passphrases are held in an encrypted, device-bound vault on your machine — not in browser storage, not in plain config files.
- SSH host keys are pinned in their own known-hosts store, so a changed host key is a warning rather than a silent reconnect.
- CLI agent credentials stay in the agent vendor's own store. MeshConsole isolates multiple accounts for the same agent by giving each one its own config home.
- Model provider keys are never held by the desktop app. Metered AI calls go through the hosted gateway, which is the only holder of provider secrets.
Agent authority is bounded
An agent's reach is a setting, not a default. Chat panes carry an explicit permission level — read-only, accept-edits, auto, or full — and a thinking budget, both applied to the running session. Destructive Pilot actions, such as closing a workspace or deleting a link between agents, are held on an approval card before they run.
Commands an agent aims at a remote SSH session pass through a per-profile policy that you configure. Under a restricted trust level, destructive commands are blocked outright, and every agent-originated command is written to an audit log. Commands you type yourself are never intercepted — the governance applies to programmatic injection.
When the embedded VS Code IDE is wired to your agents, agent-authored file writes are presented as a diff you accept or reject. Nothing lands on disk through that bridge without a human in the loop.
Account and key scoping
- Desktop sign-in uses a browser-based authorization flow; the desktop app receives a scoped token rather than your primary credentials.
- Your MeshMCP key is a signed, per-account token. It embeds the account it was minted for, so a key copied to another account is rejected rather than silently adopted.
- Hosted identity is always derived from the live session. A stale key left behind on a shared machine cannot resolve to the previous user's account.
- Plan and capability checks fail closed: if the control plane is unreachable, paid features error instead of falling open.
Releases and updates
Desktop updates are cryptographically signed and verified by the updater before they are applied, and release artifacts are published from a public releases channel so you can check what you installed. Dependencies and the codebase are reviewed in periodic internal security audits, and findings are remediated before the next release ships.
Responsible disclosure
If you believe you have found a vulnerability, write to security@meshpilot.in with enough detail to reproduce it. Reports are acknowledged and triaged, and we will coordinate with you on remediation and timing. Please do not test against other people's accounts or data.
Related
See the for what we collect, and the for your responsibilities when running agents.
Last updated: 2026