Policies & approvals

This page covers how LaunchZero governs requests through monitored tools and LaunchZero-managed integrations: gate in the moment, verify after the fact. Effective policy resolves each governed request to Allow, Require approval, or Deny.

Safe and usable by default

Under the recommended Balanced posture, common reads may be allowed, selected writes and sends ask for approval, and unknown calls deny. Effective policy determines the outcome. Explicit, scoped runtime access grants can reduce repeated prompts for a folder or host without silently widening the boundary. LaunchZero-managed integrations can ship with their own policy templates; foreign MCP entries remain unchanged until you explicitly adopt or reinstall them through LaunchZero.

You review and adjust policy in the dashboard - hand-editing files is an advanced path, not the standard workflow.

The three verdicts

Every governed request resolves to exactly one:

Verdict	What it means
Allow	Runs immediately, under a scoped capability token. No human in the loop.
Require approval	Pauses and raises an approval card; runs only if you approve.
Deny	Blocked and recorded. Nothing executes.

Under Balanced, unknown calls fall back to Deny. Another posture or a narrower effective rule may produce a different outcome.

The approval workflow

When a call resolves to Require approval, it doesn’t run. It pauses, and LaunchZero raises a real-time approval card showing exactly what the agent wants to do - the tool, the arguments, the target. State-changing calls are gated before execution, not flagged after the fact.

The card isn’t a summary you trust on faith. The exact action shown is the one cryptographically bound for execution, so what you see is what runs: at execution time LaunchZero re-checks that the action about to run is byte-for-byte the one you approved (canonical action hashing). If injected text mutates the action between your approval and execution, the hash diverges and the call is denied instead. You approve an action, not a description of one - the core of LaunchZero’s action-substitution control.

Open Advanced details when you need the durable identifiers behind that decision: the Approval ID, Correlation ID, and Canonical Hash that bind the review to the later execution record.

Capability tokens

When effective policy permits a governed action, the Executor carries it out under a short-lived, single-use execution capability scoped to that action. Durable grants are a separate policy choice: they are explicit, scoped, and reviewable until revoked or expired.

The audit trail

Governed calls, approvals, denials, and executions are recorded with their provenance - the durable, after-the-fact record of what the agent asked for, what policy decided, what you approved, and what ran. You browse and export it from the dashboard’s Activity page.

time	action	outcome
14:22:09	gmail · list_messages	allow
14:22:18	gmail · send_message	require approval → approved by you · hash matched
14:23:05	gmail · delete_message	require approval → denied by you

Under the hood: the two policy layers

LaunchZero governs your agent through two surfaces, and it keeps them in sync for you:

1. The global security posture

Your overall stance is a posture - Locked down, Balanced, Permissive, or Custom - with a default outcome, write-approval setting, and trust thresholds. Balanced is the recommended starting posture. You switch or tune it in the dashboard under Security posture, and effective posture constrains the narrower rules below it.

2. Per-integration policy

Each LaunchZero-managed MCP integration gets its own policy deciding which of that integration’s tools are allowed, held for approval, or denied - a small YAML file LaunchZero manages (and you can edit in the dashboard). On disk the verdicts are allow, require_approval, and deny (the UI shows them as Allow, Require approval, Deny). This is the shipped Gmail template:

# policy.yaml - gmail integration
version: 1
integration: gmail
default: deny
tools:
  list_messages: allow
  search_messages: allow
  get_message: allow
  send_message: require_approval
  delete_message: require_approval

Tool names are the integration’s own - Gmail uses snake_case (send_message), Outlook uses kebab-case (send-mail). LaunchZero validates every entry against the integration’s real tool list, so a typo is rejected rather than silently ignored, and anything not listed falls through to default (deny). A few tools - such as LaunchZero’s own bridge tools - are locked to deny and can’t be opened up.

Network and workspace access

“Network restricted” isn’t a policy.yaml rule - it is a separate host allowlist. LaunchZero-governed network tools can reach only allowed hosts. Model-provider traffic and disclosed direct capabilities are outside this allowlist. A workspace-folder allowlist sets which folders monitored file tools may read and write. Both are managed in the dashboard under Settings → Network & Workspace.

Next steps

• Security model - the trust domains and threat model the policy engine runs inside.
• Configuration - where LaunchZero keeps these files, and what advanced users can inspect.