Governance
Autonomy you can hand to an auditor.
Anyone can run ten agents. The hard part is answering for what they did. Maestro constrains what an agent may do, verifies what it did, controls who accepts it, and keeps the record that proves all three. Enforced in the server, not the UI.
The loop
Four controls. One closed loop.
Each is useful alone. Together they are a chain of custody for machine-written code — the thing a security review actually asks for.
Policy
constrains what the agent may do
Gates
verify what it did
Queue
controls who accepts it
Audit
proves all of it
In detail
What each control actually does.
01 —
Audit trail
An append-only record of who dispatched what, every command each agent ran, every permission granted and by whom, and who approved each merge — down to the commits that landed and the gate run that authorised them. Written server-side at the enforcement points, never reconstructed from a chat log. Other tools can stream telemetry at a SIEM; none of them can name the gate run and the two humans behind a commit, because none of them gate the merge.
“Show me the approval chain for this change.”
▪ append-only · no edit path
▪ every tool call recorded
▪ JSONL export per org
02 —
Pre-merge gates
Declare your checks in maestro.toml and Maestro runs them itself in the agent’s worktree. The merge stays locked until the run is green — and still fresh. Gate definitions are read from the main checkout, so a worker cannot edit its own gates away, and any commit or stray edit after a pass invalidates the run.
maestro.toml · read from main, not the agent's branch
“How do you know it didn’t merge something broken?”
▪ specs read from main, not the branch
▪ content-signed · a late edit stales the pass
▪ enforced in the merge, not the UI
03 —
Tool policy
An admin sets per-team rules over the tools themselves. Forbidden calls are auto-denied before a human ever sees a prompt — and the agent is told it is policy, so it stops working around it. A matching deny always wins, compound shell commands are never auto-allowed off a partial match, and unattended mode can be forbidden outright, including for sessions already running.
“What stops an agent pushing to main or reading .env?”
▪ deny beats allow, always
▪ mode ceiling · bypass can be banned
▪ every decision audited
04 —
Review queue
Require N approvals per team profile before anything can merge, and optionally bar the person who dispatched the agent from approving their own change. Sending work back resets the slate. Re-assigning an agent to a new task resets it too — approvals belong to the change that earned them, not the branch.
“Can one person ship agent code unreviewed?”
▪ N approvals · no self-approval
▪ rework voids prior approvals
▪ merge blocked server-side
Where we differ
Running agents is table stakes. Landing their work is not.
Parallel worktrees and diff viewers are everywhere now, including first-party. What nobody else ships is the layer that decides whether the work is allowed to land.
| Capability | Maestro | Claude Code | Agent runners |
|---|---|---|---|
| Parallel agents, one git worktree each | Supported | Supported | Supported |
| Diff review before anything lands | Supported | Supported | Supported |
| Backlog dispatch — task in, branch out1 | Supported | Partial | Partial |
| The merge is performed by the tool, never an agent | Supported | Not supported | Not supported |
| Pre-merge checks the agent cannot skip or edit | Supported | Not supported | Not supported |
| Admin tool-policy ceiling scoped to a team2 | Supported | Partial | Not supported |
| Multi-approver merge queue, no self-approval | Supported | Not supported | Not supported |
| Append-only ledger of gates, approvals and merges3 | Supported | Partial | Not supported |
| SSO with org and team scoping4 | Supported | Partial | Not supported |
| Runs entirely on your own infrastructure5 | Supported | Partial | Partial |
- 1 Claude Code reads and closes tracker tickets through MCP connectors, and Routines run on a schedule. Neither polls a backlog and opens a branch per task on its own.
- 2 Claude Code ships managed settings — machine-level policy files deployed by IT, which users cannot override. Maestro’s ceiling is set per team profile in the product, and every allow, deny and mode change is written to the same ledger as the merge.
- 3 Claude Code exports OpenTelemetry events for tool calls and permission decisions, and Anthropic’s Enterprise console exports account audit logs. Neither records a gated merge, because neither gates one: durability is whatever your SIEM provides. Maestro’s trail is append-only in the product and names the gate run and approvers behind every commit that landed.
- 4 Team and Enterprise plans include SSO for Claude itself. Maestro scopes every agent, action and audit row to an org and a team profile inside your own deployment.
- 5 The Claude Code CLI runs locally, but Claude Code on the web and Routines execute in Anthropic-hosted sandboxes. Maestro is a control plane you deploy — the code never leaves your box.
Trust posture
Nothing of yours passes through us.
Maestro is a control plane, not a middleman. No code, no credentials, no telemetry leaves the box you run it on.
Your infrastructure
Maestro is a control plane you run — a VPS, a build box, your VPC. Repos, worktrees and diffs never leave it. Caddy fronts it with TLS; the app binds loopback.
Your Claude subscription
Each seat drives its own Claude Code login on your own hardware. Maestro never holds, proxies or resells your credentials — there is no key to hand over, and nothing to violate.
Your identity provider
OIDC sign-in, deny-by-default and fail-closed. Authentication is not authorisation: an explicit allowlist decides who may operate, and viewers get read-only.
FAQ