Overview

LatchGate is a control point that sits between AI agents and the real world. Every side effect an agent triggers — an HTTP call, a database write, an email, a deployment — goes through LatchGate, or it doesn’t happen.

The problem

When an AI agent can call APIs, the question stops being “did the model produce good output?” and becomes “was this side effect authorized, bounded, and auditable?”

Every agent framework today ships the same pattern: the model decides, a tool function executes, the side effect happens. There is no consistent enforcement boundary. Credentials live in the agent process. Network egress is unrestricted. There is no signed record of what actually happened.

What LatchGate does

LatchGate replaces that loose tool layer with a deterministic pipeline:

Agent calls execute(action, params)
           │
           ▼
    ┌─────────────┐
    │ LatchGate   │  ← authentication, policy, sandbox, audit
    └──────┬──────┘
           │
           ▼
    external system (side effect happens here, or not at all)

Every call is authenticated (DPoP-bound lease), policy-checked (OPA), sandboxed (WASM), and evidenced (signed receipt). The agent never holds credentials. The agent never has direct network access. The only path to a side effect is through the gate.

Three guarantees

1. No-bypass for declared actions. If an operation is declared as a protected action in LatchGate, its side effect cannot occur outside LatchGate’s control path. The agent can submit requests, but it cannot reach targets the policy did not authorize.

2. Credentials never enter the agent. Secrets live in a SOPS-encrypted file. They are decrypted just-in-time, injected at the host I/O transport layer, and never touch the WASM sandbox or the agent process.

3. Tamper-evident evidence. Every execution produces an Ed25519-signed receipt in an append-only, hash-chained ledger. Post-hoc tampering is detectable. Receipts remain verifiable across key rotations via a historical verifying key store.

Two sandboxing layers

LatchGate provides containment at two independent levels:

WASM provider sandbox — every tool call executes in a fresh wasmtime instance with zero ambient capabilities. No filesystem, no network, no syscalls. This is always active, on every platform.

Agent process sandbox — the agent process itself (Claude Code, Cursor, custom agents) can run inside Linux user/network/mount/PID/UTS/IPC/cgroup namespaces via latchgate sandbox. The agent’s only paths out are the gate socket and an HTTPS proxy for LLM API traffic. Everything else — host filesystem, network, credentials, other processes — is absent from the namespace. See Agent Sandbox.

What LatchGate is not

• Not a prompt firewall. LatchGate controls what actions can do, not what the model decides to say or call. Prompt injection affects tool choice; LatchGate enforces the consequences.
• Not an MCP server registry. LatchGate has a first-class MCP adapter for connecting IDE agents and terminal agents (Cursor, Claude Code, OpenCode, etc.), but the core is the execution pipeline. MCP is one of several northbound interfaces — the same gate also serves the REST Action API and the SDKs.

When to use LatchGate

• Production agents with access to paid APIs, databases, email, or deployment systems
• Compliance environments that need a signed audit trail for every automated action
• Multi-tenant agent platforms that need per-tenant ACLs and budgets
• CI/CD automation where a single misbehaving action can cause incidents
• Any situation where “the agent did something” needs to be provable

When LatchGate is overkill

• Pure-read agents that never trigger side effects
• Local development where no external systems are reachable
• Prototype agents not yet ready for production integration

How to move forward

If you want to see it running: Getting Started — 60 seconds from install to first execution.

If you want to connect an IDE or terminal agent: MCP Adapter — how LatchGate actions become MCP tools.

If you want to manage it interactively: Operator TUI — the primary interface for setup, approvals, and day-to-day operation.

If you want to understand how it works: Core Concepts — actions, grants, receipts, pipeline.

If you want to deploy it: Production Quickstart — 15 minutes to a hardened production instance.

If you want to sandbox an agent: Agent Sandbox — Linux namespace containment.

If you want to review the threat model: Security Model.