Security model

The full, canonical threat model lives on the security page - that is the page to read before you trust LaunchZero with your machine, and every section here links out to it for depth. This doc is the orientation: a condensed map of how the gateway thinks, so the rest of the docs make sense.

The whole model fits in one sentence: the agent can be wrong, so requests through monitored tools and LaunchZero-managed integrations are not trusted by default. LaunchZero decides each governed request before it runs and records the decision after. Gate in the moment, verify after the fact.

The zero-trust premise

LaunchZero assumes the agent can be jailbroken, fed a malicious web page, or steered by content it was never meant to obey. Execution capabilities are short-lived and one-shot. Durable grants are explicit, scoped, and reviewable.

The policy, approval, execution, and Activity path runs locally on your machine. LaunchZero-managed integrations are registered behind per-tool policy proxies. Existing foreign MCP entries remain unchanged until you explicitly adopt or reinstall them through LaunchZero. Read the long form in the zero-trust premise.

Three separate trust domains

LaunchZero is not one process that does everything. It is split into three planes, each with a single job and a minimal interface to the others:

• GatewayServer - the control plane. Decides. Hosts the policy engine and approvals, and owns the verdict for each governed request: Allow, Require Approval, or Deny. It issues decisions, not actions.
• Executor - the execution plane. Acts, and only ever on a decision the control plane already made - under a scoped, time-limited capability token.
• HostIntegrity - the trust plane. Watches. Scores host and gateway integrity and looks for tamper signals from its own local process.

Separation gives each plane a narrow job and interface. It does not make a compromised authorized issuer harmless. The full diagram is in the control and execution split.

The per-call gating lifecycle

A request through a monitored tool or LaunchZero-managed integration follows this path. Effective policy determines whether the request runs, asks for approval, or stops:

1. Authenticate the request over the agent-facing bridge.
2. Evaluate policy to Allow, Require Approval, or Deny - default deny.
3. Verify intent by canonicalizing and hashing the exact action.
4. Approve, if required - pause and raise an approval card for a human.
5. Mint a capability - a scoped, single-use token for that one action.
6. Execute and re-check - re-hash the action and run only if it still matches.
7. Record the call, verdict, approval, and execution to the audit trail.

Each step is detailed in the per-call gating lifecycle, and you can watch one call travel it in the Quickstart.

Prompt injection and action hashing

Prompt injection is the defining threat for tool-using agents: an attacker slips instructions into something the agent reads and has it act on them. The most damaging version is action substitution - the agent decides to do one benign thing, and injected text quietly turns it into something else before it runs.

For an approved governed request, LaunchZero computes a canonical hash of the exact action, normalized to a single deterministic form. At execution time the action is hashed again and runs only if the hash matches. A changed action does not inherit the earlier approval.

step	action	hash	result
approved	Filesystem.WriteText path=report.md	a1f9…c0	-
execute	Filesystem.WriteText path=report.md	a1f9…c0	match: allow
execute	Filesystem.WriteText path=~/.ssh/authorized_keys	7b3e…d2	mismatch: deny

This control does not determine whether the original request was safe or wise. It detects a mismatch between an approved action and the action submitted for governed execution. The full treatment is in prompt injection and action substitution.

Secrets, and the trust boundary

Keys managed through LaunchZero live in an encrypted, machine-bound secret store rather than plaintext LaunchZero-managed configuration. LaunchZero-managed secrets are released only to authorized service identities; provider credentials remain within the agent’s configured trust boundary. See secret handling for the details.

Inside the boundary, monitored tools and LaunchZero-managed integrations are policy-gated; decision and execution use separate local processes; and an approved action is bound to the matching canonical action before governed execution. Model-provider traffic and disclosed direct capabilities remain outside that mediation boundary. LaunchZero is not antivirus or EDR, and it cannot make a fully compromised OS safe. A broad Allow rule remains broad. Read the full account in what is and isn’t in the trust boundary.

Read further

• The security model in full - the canonical threat model, the process diagram, and answers for the skeptical engineer.
• Features tour - the product journey from setup through verification.
• Policies & approvals - write the rules the lifecycle enforces.