Preloop
The open-source, self-hostable AI agent control plane and software factory: govern every tool and model call with one policy, budget, and session timeline.
- Source repo
- preloop/preloop
- Stars
- ★ 79
- Last updated
- today
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 84/100 · Good
At a glance
- Works with
- Universal · cross-platformCodex · Claude Code
- You'll need
- Typical use
- Platform and security teams bringing agents near production: use the MCP Firewall with policy-as-code to control every tool call and approve sensitive actions from mobile or Slack.
- Main limitation
- The organizational layer is commercial: a self-hosted OSS instance is one operator per account — users/teams RBAC, per-user/team budgets, multi-approver routing and quorums require Cloud/Enterprise.
- Source review
- 84/100 · Good
What does this agent do, and when should you use it?
Preloop is one self-hostable open-source service (Apache 2.0) that sits between your AI agents and everything they reach, governing, attributing and recording every tool and model call. Its control-plane half includes an MCP firewall that allows, denies or holds tool calls for human approval, an AI model gateway with budgets and attribution, policy-as-code in YAML and CEL, and one runtime timeline per session. Its software-factory half runs agents through Flows in hosted containers or your own runners, triggered by GitHub, GitLab, Bitbucket Cloud, Jira, webhooks or CI jobs, with 21 built-in presets that produce reviewable pull requests. Human approvals work from mobile, watch, Slack, Mattermost, email, webhook, or the CLI, and an operator can steer a running agent at any time. Deploy via Docker Compose, Helm, or Preloop Cloud; a local CLI connects to the control plane with preloop login.
Preloop intercepts and governs agent behavior. After preloop agents discover and preloop agents onboard onboard local agents, MCP tool calls pass through the MCP Firewall, which allows, denies, requires approval, or requires justification per YAML + CEL policies; model calls pass through the AI Model Gateway (OpenAI-, Anthropic- and Gemini-compatible) for budgets, allowed-model lists, and token accounting attributed by model, agent, session, API key, flow, and user. Flows start agents in hosted containers or private runners (connected over an outbound WebSocket, no inbound ports) when GitHub/GitLab/Bitbucket/Jira events, webhooks, or CI jobs fire; every tool call passes the same firewall and every model call is charged to the flow's budget, ending in a pull request. Approvals (with native Bash/Edit support) arrive via mobile, watch, Slack, Mattermost, email, webhook, or preloop approvals. Each session gets one timeline of tool calls, model calls, policy decisions, approvals, spend and outcomes. Policies ship with preloop policy apply <file>, and can be simulated with Test this rule or Simulate before saving.
- Platform and security teams bringing agents near production: use the MCP Firewall with policy-as-code to control every tool call and approve sensitive actions from mobile or Slack.
- Engineering teams running Claude Code, Codex CLI, or Cursor who need cost visibility: the Gateway attributes spend by model, agent, session, and API key, and caps it with budgets.
- Teams on Jira or GitHub who want tickets turned into bounded agent work: a flow implements an issue automatically and the Pull Request Reviewer preset reviews the resulting PR.
- Security teams facing CRA / EU AI Act pressure: run security audit presets (SBOM verify, exploit check, release audit) to collect evidence packs, plus DORA exports.
- Platform teams needing FinOps visibility: inspect gateway spend per model and flow, import Copilot usage, and use the account kill switch to block traffic in an emergency.
How do you install or deploy this agent?
The fastest path is Preloop Cloud (the CLI is a client); self-hosting uses Docker Compose and keeps data on your machine.
# 1. Install the CLI (macOS / Linux / WSL)
curl -fsSL https://preloop.ai/install/cli | sh
# Windows, native (PowerShell):
irm https://preloop.ai/install/cli.ps1 | iex# Self-host (Docker Compose, data stays on your machine)
curl -fsSL https://preloop.ai/install/oss | shA self-hosted instance requires SECRET_KEY or it refuses to start; the development docker-compose.yml ships development-only credential defaults that you should override with a .env file (start from .env.example). The console is at http://localhost:3000.
How do you use this agent?
The CLI is a client that connects to a control plane: Preloop Cloud or your self-hosted instance.
# Cloud (fastest)
preloop signup
# Or your self-hosted instance
preloop login --url http://localhost:3000
# Discover and onboard local agents
preloop agents discoverpreloop agents discover finds local agent configs and reports what each adapter supports; preloop agents onboard routes calls through the MCP Firewall and Gateway. To talk to a running agent, install the runtime plugin with preloop agents install-plugin (or preloop claude for Claude Code). Example policy:
version: "1.0"
metadata:
name: "Production Safeguards"
approval_workflows:
- name: "deploy-approval"
timeout_seconds: 600
required_approvals: 1
async_approval: true
tools:
- name: "bash"
source: mcp
approval_workflow: "deploy-approval"
justification: required
conditions:
- expression: "args.command.contains('deploy') && args.command.contains('production')"
action: require_approvalShip it with preloop policy apply <file> (validate / diff / export also exist); trigger flows with preloop flow trigger or the run-flow GitHub Action.
What are this agent's strengths and limitations?
- One policy, budget, and session timeline covers both local agents and flow agents — a single component replaces separate vendors for tool firewalling, model gateway, approvals, and observability.
- Apache 2.0 and self-hostable: data stays on your network (except an optional daily version check), a credible open-source alternative to AWS Bedrock AgentCore with VPC/on-prem deployment, YAML+CEL policy, MCP-native governance, and mobile/Slack approvals.
- 21 ready-made flow presets ship in the repository (PR review, automated issue implementation, security audits, delivery reports), extendable via private runners, flow delegation, and the run-flow GitHub Action.
- Rich, auditable approval channels: mobile, watch, Slack, Mattermost, email, webhook, and CLI, including single-approver workflows and native Bash/Edit approvals.
- The organizational layer is commercial: a self-hosted OSS instance is one operator per account — users/teams RBAC, per-user/team budgets, multi-approver routing and quorums require Cloud/Enterprise.
- Self-hosting is real infrastructure: Docker Compose or Helm is required,
SECRET_KEYis mandatory, the Helm chart refuses placeholder jwtSecrets, and Docker Compose and Helm are the only supported install surfaces (no Terraform modules). - A daily pseudonymous telemetry version check is on by default (disable with
PRELOOP_DISABLE_TELEMETRY=true), and the development docker-compose ships development-only credential defaults that must be overridden for production. - Community surface is small (Discord-centered), and the boundary between open governance and commercial features requires reading the editions documentation.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Preloop This agent | 84 · Good | — | ★ 79 | today | Python | Codex · Claude Code |
| Auto Browser | 62 · Some gaps | Self-hosted serviceFree + model costs | ★ 916 | today | Python | OpenAI API · Claude API |
| OpenOps | 59 · Major gaps | Self-hosted serviceFreemium | ★ 1.1k | 1d ago | TypeScript | — |
| Agentspan | 62 · Some gaps | CLIFree + model costs | ★ 499 | 29d ago | TypeScript | OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
The materials describe restricted CI identities scoped by account, project, flow, and action; separation from human permissions; approval gates; encrypted credentials; and log redaction. The privacy guide explains default content capture, how to disable it, telemetry, and data flows. Audit chains, signed records, and self-hosted rollback constraints are also described concretely. Dependency security receives only a general update requirement, with no dependency inventory or itemized mitigation evidence, so that score is low. External notifications, models, and repository access are documented, but confirmation or recovery paths are not shown for every operation. Publisher identity is unverified and attribution evidence is limited.
The documents give connected descriptions of the control plane, approval, and runtime paths, and identify boundaries and gaps, such as the git guard having no production callers. Some statements remain product assertions or design notes, and the child-approval note says it was verified on a different revision, so consistency is not fully established. Dependency availability is covered mainly through installation prerequisites, without complete evidence of dependency failure handling or availability guarantees. Failure behavior includes denials, timeouts, blocking, and some error categories, but coverage is not comprehensive.
The README identifies platform security teams, engineering teams, and event-driven work as target scenarios, and names compatible agents. The documents give concrete boundaries for restricted CI, approvals, the model gateway, and security evidence packs, including that evidence packs are not certification or legal advice. Trigger sources, restricted request shapes, permitted actions, and refusal conditions are detailed. Cloud, self-hosting, Docker Compose, Helm, Windows CLI, and private runners are covered with deployment prerequisites.
The README organizes material around onboarding, capabilities, deployment, editions, and repository workflows, with links to architecture and operator guides. Installation notes cover prerequisites, interactive and unattended configuration, ports, upgrades, and troubleshooting. Examples, guides, and known limits are extensive; Apache-2.0 is identified in metadata and the README. Naming and version cues exist for the CLI, components, and versioned protocols, but the supplied material lacks a complete changelog, limiting stability evidence. Contribution, release, and security-reporting paths are present, but maintainer identity and long-term responsibility are not fully specified.
The product produces policy decisions, approval records, session audits, budget attribution, and pull requests and evidence packs for human review. The materials include directly usable policy and command examples. Combining tool governance, a model gateway, and event-driven agent runs supports clear compositional value. Cost effectiveness is only supported by budget and spend attribution features and self-hosting options; no operating costs, resource requirements, or comparable measurements are provided.
Important claims commonly point to specific guides, endpoints, modules, settings, or policy examples. Security materials distinguish platform facts, stated limitations, and design notes. Multiple files support installation, privacy, approvals, and restricted CI, but they are mostly documentation from the same project, so independent corroboration is limited. The materials explicitly label a design note as non-normative, distinguish implemented work from planned work, and state limits on scanning and evidence packs, supporting a sound separation of fact and inference.
- Self-hosted deployments still send optional daily version-check telemetry; the materials say it can be disabled with PRELOOP_DISABLE_TELEMETRY=true.
- The model gateway stores pattern-redacted conversation content by default. Set MODEL_GATEWAY_CAPTURE_CONTENT=false if content should not be stored, and review redaction boundaries for each data surface.
- The security document lists gaps, including partial rate limiting, no MFA, and incomplete implementation of dependency updates and regular security audits.
- The child-approval material is labeled a design note and says it is based on a different revision; it should not be treated as runtime verification for the reviewed revision.