// Security review
How Mendr earns write access to your code
Mendr pushes branches and opens pull requests on your repositories, so you deserve more than a badge wall. This page describes the system as built — the exact lifecycle of a repair, the permissions behind it, and the guardrails around the AI — so your security team can evaluate it on the mechanics.
Last updated October 2026 · reflects the current implementation
The lifecycle of a repair
Every fix follows these seven steps. Mendr's servers, not the agent, hold the GitHub write credential, publish the pull request, and tear down the sandbox.
- 01
Scoped credentials are minted
Mendr requests fresh GitHub installation tokens scoped to one repository and the exact phase: contents-read for the checkout, then contents and pull-request write for publication. GitHub expires them within the hour. Only the read token enters the sandbox, for the checkout. The repair agent never receives a GitHub token.
single repository · phase-specific permissions · short-lived
- 02
A single-use sandbox boots
Every repair gets its own isolated virtual machine with a bounded provider lifetime. Mendr records the sandbox identity, deadline, and cleanup state, so a crash cannot silently hand the same environment to another repair.
never shared between repairs · recorded deadline and cleanup state
- 03
A minimal checkout is prepared
Trusted code creates an empty repository in the sandbox and fetches only the pinned base commit, with no history and no tags. It checks that commit out detached. Git hooks are disabled, so the checkout does not run repository code. No remote is configured.
single commit · no history · no tags · hooks disabled
- 04
The AI agent works inside a narrow boundary
The repair agent runs as an unprivileged user and can reach only Mendr's fixed allowlist of model, GitHub, advisory, package-registry, and documentation hosts. A provider-level firewall blocks every other destination. The agent reaches the model through a gateway that Mendr controls. The model key and the GitHub credential are never in the agent's environment.
unprivileged user · fixed host allowlist · no GitHub token
- 05
A candidate is independently reviewed
When the agent exits, Mendr stops its remaining processes and removes its write access. Trusted code freezes the candidate, enforces the file and byte budgets, and blocks changes to .env files, to .github/, and to how your repository resolves packages, runs code, or assigns reviewers. A second AI session then reviews the frozen candidate as a different user with read-only access.
agent fenced · frozen candidate · read-only reviewer
- 06
Publication is recorded before it happens
Before it publishes, Mendr saves the branch name, the accepted candidate commit, and a run marker. It checks the candidate against the content rules again, with your base branch read from GitHub, before its first write. It creates a new branch and never overwrites an existing one. If a publication result is uncertain, Mendr accepts only the one PR that matches the saved branch, commit, marker, and App identity. Review handoff follows your policy: draft, ready, or ready after verification.
durable intent · no branch overwrite · marker-bound PR
- 07
Cleanup is durable too
Mendr destroys the sandbox when the repair publishes, pauses for an owner answer, or reaches a final result. If Mendr cannot confirm cleanup, it keeps the capacity reserved until recovery stops the sandbox. It never assumes that an uncertain sandbox is gone.
fenced on shutdown · cleanup confirmed · ambiguity fails closed
Access, precisely scoped
Mendr connects through a GitHub App that you authorize, with the minimum permissions that let it do the job. Every token expires within an hour. Fix tokens are scoped to one repository and one step: read for the checkout, then write for publication. Tokens for scans and for pull-request status and updates cover the repositories that you gave the App.
What Mendr can do
App permissions you approve
- Read repository metadata, dependency manifests, and security alerts
- Read organization membership to verify workspace roles
- Read check results and GitHub Actions logs, which Mendr uses for its own pull requests
- Create branches and push commits
- Open pull requests, and update their title, description, and ready state
What Mendr does not do
Its own rules, enforced in code before publication
- Publish changes to .env files or anything under .github/, including workflows
- Publish changes to install scripts, Git hooks, CI configuration, CODEOWNERS, package-manager settings, or lockfile sources
- Merge pull requests
- Push to any branch other than a new mendr/* branch
What Mendr cannot do
Not granted to the App
- Change organization settings or membership
- Read repository secrets
- Bypass branch protection, which applies to Mendr like any contributor
Inside the sandbox
Every repair runs in an isolated, disposable environment with these properties built in — none of them optional, and none of them weakened per repair.
Fresh VM, every time
Repairs never share infrastructure. Each repair runs in its own isolated virtual machine created on demand, and Mendr keeps the capacity reserved until it confirms that the machine stopped.
Network access is default-deny
A provider firewall permits only Mendr's fixed allowlist of model, GitHub, advisory, package-registry, and documentation hosts. The agent cannot add destinations.
Credentials stay out of reach
The agent's environment is allowlisted. The repository read token is used for the checkout and is never present in the agent's environment. The model key stays in a gateway process that the agent cannot read.
Your code runs only inside the sandbox
By default, the repair agent decides which builds and tests to run. A repository setting can require them or skip them. Install scripts, builds, and tests run as the unprivileged agent user, behind the same network allowlist, without GitHub credentials or the model key. The pull request reports which checks ran.
Bounded lifetime
Repair runtime is bounded, and the deadline is recorded. Expired or missing sandboxes are reconciled explicitly instead of being assumed gone.
Persistent output is minimized
For new fixes, Mendr keeps bounded evidence: structured reports, counts, candidate identifiers and changed paths, owner responses, publication records, and failure summaries. It does not keep standalone copies of every changed file, the complete diff, the model event stream, or the full command log. Retained text can still include excerpts of source, diffs, prompts, commands, or output. Today this evidence is kept until the workspace is deleted. Mendr is building automated deletion after a fix ends and will state the period here when it is active.
Guardrails on AI-authored changes
The agent proposes; it does not decide. The sandbox limits what the agent can reach, and trusted code checks the frozen candidate after the agent is fenced, before publication.
Secret files and GitHub configuration are never published
Mendr rejects a candidate that changes a .env file at any depth or anything under .github/, including workflows, and returns it to the agent to remove those changes.
Changes to how your code runs are blocked
Trusted code compares each changed file with your base branch, before the independent review and again before publication. It rejects lockfile entries that do not come from a package registry, integrity hashes that change without a version change, changes to install scripts and Git hooks, task-runner files, package-manager and toolchain settings, CODEOWNERS, CI configuration, and new executable files or symbolic links. The agent gets each reason and can remove those changes. These rules do not judge the fix. The independent review and your own code review decide whether each change belongs in it.
Sensitive folders stay in draft
A repair can change files in a folder named auth, crypto, migrations, or payments, at any depth, when the fix requires it. The pull request then lists those files and always opens as a draft, whatever your review handoff policy. Draft status does not stop your CI: GitHub runs pull_request workflows for the Mendr branch, with your repository's secrets, when the pull request opens.
A strict change budget
Each fix has a budget for the number of changed files and the size of changed contents and diffs, set before the fix starts. Candidates that exceed it are rejected before publication. Mendr shares the current limits on request.
The agent cannot open PRs
The agent has no GitHub write credential, so it cannot push a branch or open a pull request. Mendr records publication intent and opens the PR only after the independent review accepts the candidate, using your review handoff policy. AI text in the pull request cannot mention people or render HTML. It links only to github.com, to the fix's Jira tickets, and to addresses that your pull request template already contains.
Review is independent
Mendr never trusts the agent's own report. A separate AI session reviews the frozen candidate as a different user with read-only access. Publication then checks that each blob, the tree, and the commit match the candidate that the reviewer accepted. Your CI runs on the pull request after that.
What we keep, and what we don't
Full checkouts are temporary
Scans use temporary checkouts on Mendr infrastructure; repairs use a separate single-use sandbox. Each checkout is removed when that work ends. Mendr can retain selected repair evidence and publication records, including repository-content excerpts, but it does not retain the temporary checkout itself. Exposure analysis sends advisory text, dependency chains, file paths, and bounded source excerpts around import sites to its decision provider, and batch planning sends the repository name, package versions and the build and test setting; never Mendr's credentials and never the clone.
Secrets encrypted at rest
Stored credentials and fix evidence are encrypted with AES-256-GCM. GitHub access tokens are minted per operation, used, and discarded. Mendr does not store them.
Material actions are audited
Scans, fix requests, pull-request events, and role changes land in an audit trail that workspace admins can export.
Security teams can ask for the named list of providers and the current limits at hello@mendr.sh.
Report a vulnerability
Send an email to hello@mendr.sh with "Security" in the subject. Do not open a public issue. Tell us what you found, the steps to reproduce it, and the impact that you expect.
The security policy gives the scope, the rules for testing, and our promise not to take legal action against good-faith research.
Evaluate it yourself
The fastest way to assess Mendr is to watch it work: connect a repository, let it open a pull request, and inspect the diff, the branch, and the audit trail it leaves behind. Your team reviews the changes and merges the pull request on GitHub.