Autonomous coding agents.
Controlled permissions.
Checkable approvals.
MergeWarden turns a coding agent into a controlled development process: an approved plan, independent review, criteria-bound acceptance, and a binding gate before merge.
The agent can propose work and change code. It does not decide itself whether that work gets approved.
- Approval tied to a specific plan
- Git host credentials stay outside the agent (broker mode)
- Pipeline re-checks independently
The lifecycle
Five steps, each with its own requirement
Plan
The agent writes a plan. A human approves it before any code exists.
Implementation
The agent works on a feature branch. The run's state lives there, not in the agent itself, which can restart at any time.
Review
An automated, rule-based review checks architecture, security, test quality, and more. Every finding has a traceable origin.
Acceptance
The criteria recorded in the ticket are checked against the actual state, not against a claim.
Gate
Nothing merges until every requirement is met. No exception the agent can grant itself.
Comparison
More than a review agent
| Capability | Plain MR review | MergeWarden |
|---|---|---|
| Checks the diff against rules | Yes, depending on the system | Yes |
| Checks the whole development process | Not necessarily | Plan through acceptance and gate |
| Ties approval to a specific plan state | Not necessarily | Yes |
| Treats agent-reported state as untrusted | Not necessarily | Explicit architectural principle |
| Checks acceptance criteria against the actual code | Not necessarily | Its own acceptance step |
| Re-evaluates independently in the pipeline | Depends on the integration | Part of the design |
| Keeps git host credentials away from the agent | Depends on the architecture | Via broker mode |
"A review agent judges a change. MergeWarden controls the conditions under which a change may come into existence, get reviewed, get approved, and get merged."
The principle
"State can only raise the requirement, never lower it."
Any state the agent reports or influences can never weaken a requirement, only tighten it. An agent cannot talk its way into approval by claiming something is already done or already checked. That is the trust boundary between agent and approval.
Code decides, not the model:
- whether an approval is valid
- whether a phase transition is allowed
- whether the plan covers every criterion
- whether tests pass, and whether any were weakened
- whether a merge request can even be created
Locally, the agent can still write a review fingerprint, an acceptance result, or a retry counter into the branch state. Those fields protect against mistakes, not against an agent that deliberately works around them. What actually holds against that case is the pipeline, which recomputes every condition from the git host's own record, and code approval on the host itself, which the agent cannot grant to its own merge request.
Architecture
Trust boundaries
In broker mode, the agent never reaches the git host directly. The gate opens only once human approval and an independent pipeline check both exist.
Attack → countermeasure
Six concrete cases
Manipulated status or fabricated evidence
The agent claims a criterion is met or a check has passed.
MergeWarden. The pipeline evaluates the governing conditions independently; agent-reported state cannot weaken a required control.
Plan changed after approval
An already-approved plan no longer matches the current content.
MergeWarden. Plan approval is tied to the confirmed plan state; any change invalidates the old approval.
Agent compromised or influenced by prompt injection
The agent tries to reach privileged actions beyond its actual task.
MergeWarden. In broker mode, the runner mediates defined operations instead of handing git host credentials directly to the agent.
Acceptance criterion met on paper only
A plan maps a criterion to a solution, but the actual implementation does not meet it.
MergeWarden. Acceptance checks the criterion against the actual state, not just against the mapping in the plan.
Manipulated ticket tries to reach credentials or the network
A crafted ticket text tries to get the agent to read SSH keys, cloud credentials, or any network target.
MergeWarden. A security profile blocks credential files, denies environment variables by default, and allows only an approved network list. If the sandbox cannot start, the agent does not start.
Manipulated merge request title or description
An attacker tries to steer the automated reviewer through the merge request text.
MergeWarden. Title, branch name, and description are never inserted into scripts. The reviewer has no Bash, WebFetch, or WebSearch, only read access to its input.
Who it's for
Teams running agents in production, without blind trust
MergeWarden is for teams that let AI coding agents take on real work but do not want to just trust them to follow instructions. The gates apply no matter which model or vendor drives the agent.
model-agnosticValue by role
A different reason for every role
Developer
The agent works largely on its own; you are only pulled in when it actually matters, at plan approval and at the final approval step. No need to watch every intermediate step.
Engineering lead
Fewer questions and correction loops, because rules already apply during planning. Every finding is traceable (model, effort, origin), no opaque judgment calls.
Security
Credentials to the git host stay outside the agent in broker mode. The security review target always runs and cannot be turned off. Every approval is tied to an actually checked state, not a claim.
Platform team
A rule set you can extend per project without maintaining your own copy of the whole plugin. Runs on GitLab and GitHub. Configuration lives in the repo itself, not in external infrastructure.
Leadership
Agents work productively without approval processes getting watered down. A traceable record through origin and ticket binding. No dependency on a single model vendor.
Integration status
What already runs today
The trust model is agent-agnostic. Any agent that opens a merge request through the normal git flow can be gated the same way. The available integration today is Claude Code.
- GitLab CI. Actively used in production, MergeWarden's own pipeline runs on it.
- GitHub Actions. Reference template exists.
prepareand all reviewers ran correctly with a real model in real GitHub Actions. The full run fromevaluate/gatethrough to actually blocking a merge via branch protection is still open. - Rule set. Extensible per project, custom review targets and approval rules come in cleanly, existing ones can be replaced or turned off.
- Reviewer model and effort. Configurable per project.
Pricing
License model
Tiered by team size and number of repositories, not by pipeline runs.
| OSS | Single | Team | Business | Enterprise | |
|---|---|---|---|---|---|
| Price | free | ||||
| Scope | single license per project | 1 developer | up to 10 | up to 50 | custom |
| Repositories | 1 public open-source project | up to 2 | up to 5 | up to 25 | unlimited |
| Git host | GitHub or GitLab | GitHub or GitLab | GitHub or GitLab | both | both |
| Support | community | community | priority | SLA, onboarding, audit |
OSS applies to one public repository under a recognized open-source license. Term for the other tiers: 12 months, auto-renewing with a notice period. The customer covers model costs through their own API access; MergeWarden sells the control layer, not compute time. A pilot run from ticket to merge request is recommended before signing, see Demo below.
Demo
What you'll see in the demo
A real run on a real ticket: an approved plan, implementation on the feature branch, a review run with a blocking finding, and the subsequent approval once every requirement is met. The demo takes 45 to 60 minutes, and you don't need to prepare anything, we run the walkthrough.
FAQ
A closer look
Does this work with the coding agent I already use?
MergeWarden runs as a Claude Code plugin today. The gate, the pipeline checks, and the broker mode are not tied to one vendor. Any agent that can open a merge request through the normal git flow can be gated the same way. Support for other agent runtimes is a matter of writing the integration, not changing the trust model.
Where does the agent's work actually run, on my machine or somewhere else?
Wherever you run the runner: your own machine, your own CI, or a self-hosted GitLab or GitHub
runner. MergeWarden does not run a hosted service that executes your code. By default, the agent
itself never holds credentials to the git host. A separate broker process talks to the git
host instead, for both GitHub and GitLab. If you want the agent to
hold its own git host token, you can set that explicitly with zugang = "direkt".
Does the pipeline run my project's tests?
No, the agentic check never checks out or executes the merge request's code. It only reads the diff as text. Classic unit tests are independent of that. You can run them as an ordinary CI job before or alongside the agentic check, for example in the same pipeline. The gate itself does not check whether that job is green, so add your test suite as a required check in branch protection yourself.
What happens if the review step fails to run, for example a model outage or a session limit?
The gate defaults to requiring a human review instead of merging anyway. A missing or failed check counts as "not satisfied," not as "skip."
Is this the same as a review bot or linter?
A review bot adds a check. MergeWarden adds a merge gate. Plan, implementation, review, and acceptance run as a fixed sequence, and the agent's own status reports can only raise what is required before merge, never lower it. The six attack cases above show what that boundary catches and what it does not.