Home/Docs/About/Security Model

How bake handles write access and security.

Security Model

Design principle

bake is a CLI that deploys real programs to real blockchains. The security model is designed around one principle: an agent cannot be tricked into calling a tool it does not know exists.

MCP safety model

Read-only by default

bake mcp starts in READ-ONLY mode. Write tools are not registered at all โ€” not "registered but blocked."

Policy-gated writes

To enable writes, create a policy file:

json
{
  "allowWrites": true,
  "maxDeploysPerSession": 5,
  "requireConfirmation": true
}

Confirmation flow

When requireConfirmation: true:

  1. Agent calls bake_deploy
  2. Server returns preview + confirmationToken
  3. Agent (or human) calls bake_confirm_action with token
  4. Server executes

A real deploy cannot complete in a single unsupervised tool call.

Session limits

maxDeploysPerSession caps writes per MCP server process. Counter resets on restart.

Audit logging

Every write attempt is logged to stderr with ISO timestamp.

Audit gating

bash
bake deploy --require-audit

Runs Radar (Auditware's static analyzer) before deploying. Refuses to ship critical/high findings.

There is deliberately no --ignore-audit override.

Radar

bake implements no security heuristics of its own. All findings are Radar's, labelled "powered by Radar."

See Audit with Radar for details.

What bake never does

  • โŒ Never signs transactions that aren't deploy-related
  • โŒ Never exports private keys
  • โŒ Never shares sessions with the dashboard
  • โŒ Never auto-installs security scanners silently
Sourced from local MDX in docs/content/docs