Security & Approvals

@zlogic.run's default security boundary: the model may propose actions, but sensitive actions require local client approval before execution.

Approval layers

The permission gate checks every tool call before it runs:

Layer	What happens	Examples
Layer 0 — Deterministic rules	Hard-coded rules decide Allow / Ask User instantly. No model call needed.	Safe read-only operations (read_file on non-sensitive paths, safe exec heads), write_file inside workspace
Layer 1 — Model review	The conversation's own model reviews the request against the rulebook and returns a verdict, falling back to the light tier when it is unavailable.	Everything that Layer 0 couldn't decide
Layer 2 — Deep model review	If Layer 1 is uncertain, the same model re-reviews with the same rulebook, falling back to the main tier when it is unavailable.	Complex shell pipelines, unusual write paths
User prompt	If all auto-approval layers say "ask user", the client shows a confirmation dialog with scope options.	Dangerous operations, sensitive files

⚠️ Limitations of auto-approval

The auto-approval system (Layers 0–2) uses deterministic rules and LLM review to improve efficiency, but it cannot guarantee 100% accuracy. User confirmation is the last and most important layer of the security model — before every sensitive action executes, you have the opportunity to review and decide. Do not rely solely on auto-approval rules to defend against malicious behavior.

Grant scopes

When approving or declining, you can specify a scope:

• once: allow this one time only
• session: don't prompt again in this session
• project / always: persist per working directory (stored to disk)

Existing grants can be managed via the grant list UI.

Approval modes

• ask (default): the gate above runs; nothing sensitive executes without your confirmation.
• deny: auto-deny — a non-interactive fail-closed posture (CLI --permission deny).
• approve-all: everything is auto-approved (CLI --permission approve-all / --god). Use only in local development; God Mode is not meant for untrusted environments.

Auto-approval rulebook (Layer 0)

The deterministic rules fall into two categories:

Danger rules — always ask the user:

Rule	Description
D1	Destroys data irreversibly — recursive/forced deletion outside workspace, overwriting unrelated files
D2	Reads, writes, or transmits secrets — .env files, private keys, credentials
D3	Escalates privilege or alters system state — sudo, system services, /etc
D4	Publishes or deploys — package publish, force push, release creation
D5	Exfiltrates — sends local file contents or repo data to a remote host the user didn't name
D6	Installs persistence — shell rc/profile, git hooks, login items
D7	No plausible connection to the user's request, or contradicts it

Category rules (C1–C6):

• C1 read_file / list_dir: non-sensitive paths pre-approved; sensitive target triggers D2
• C2 write_file inside workspace: pre-approved unless D2/D6 matches
• C3 write_file outside workspace: judge by directory (temp dirs allowed, system dirs ask)
• C4 exec: builds/tests/linters/formatters allowed; D-rules and git push require user confirmation
• C5 network: public GET allowed; mutations and private hosts ask user
• C6 other tools (MCP/plugins): apply D-rules to the action

Sensitive path patterns

When the agent reads or writes files matching any of the following patterns, Layer 0 immediately escalates to ask user (D2):

Target	Example paths
Environment files	.env, .env.production, .env.local
SSH keys	~/.ssh/id_rsa, ~/.ssh/id_ed25519, ~/.ssh/authorized_keys
AWS credentials	~/.aws/config, ~/.aws/credentials
GitHub CLI auth	~/.config/gh/
GnuPG	~/.gnupg/
Docker config	~/.docker/config.json
kubectl config	~/.kube/config
Private key files	any file ending in .pem or .key
Private key names	id_rsa, id_dsa, id_ed25519 (any location)
Credential dotfiles	.npmrc, .pypirc, .netrc

Additional patterns can be configured through paths rules in policy.yaml (global or per-project).