GitHub App Permissions

Effective date: 15 September 2026

Enji Guard uses a GitHub App to work with your repositories. This page explains why, what it can read and write, what it does not do by default, and how to revoke access.

The app is called Enji Fleet

On GitHub the app is named Enji Fleet, not Enji Guard. Enji Fleet is the agents orchestrator that actually runs the audits, and it is the same product — but it is the name you will see on the install screen.

Why Enji Guard uses a GitHub App

On GitHub, Enji Guard connects through a GitHub App rather than a personal access token. A GitHub App gives scoped, per-installation, revocable access to the repositories you choose, with permissions declared upfront and visible to you before you install — and it belongs to no individual, so it does not break when someone leaves your team.

GitLab works differently. GitLab has no equivalent app installation, so a GitLab connection uses an access token you create and give to us. That model, its scopes, and the webhooks it involves are covered on the GitLab Access page.

What the app asks for

These are the permissions shown on the install screen:

Why this permission is broader than our use of it

GitHub does not offer a narrower permission meaning “may create a branch and open a pull request”. Write access to code is the level that allows it, and it is the level we have to ask for.

That permission would technically allow pushing directly to any branch, including your default branch. We do not do that. We create branches and open pull requests for you to review, and Terms of Service section 16 commits us to it: we do not merge pull requests and we do not deploy code. The permission is broader than our use of it.

Which repositories

You choose at install between:

• selected repositories — only the ones you pick; or
• all repositories, which includes repositories created later.

Either way, GitHub also grants the app read access to your public repositories. That is how GitHub Apps work rather than something we ask for, but it is worth knowing.

When the app reads your code

The installation stays in place until you remove it — it is not created and destroyed around each audit. What is limited is the use: we read your code when an audit runs, and each audit runs in an isolated, ephemeral workspace that is removed afterwards together with the cloned code.

What we are told about, and when

Reading your code happens when an audit runs. Separately, the app subscribes to three kinds of GitHub event, so that code review and activity tracking can respond to what happens in your repository between audits:

These arrive whenever they happen, not only while an audit is running. They carry the activity itself — who did it, the title and text of the issue, pull request or comment, and identifiers for the repository and branch. They do not carry the contents of your code.

We are not subscribed to push events. We are not told when someone commits to your repository. The one indirect exception: pushing to a branch that has an open pull request updates that pull request, so we are told the pull request changed — not what the commit contained.

We are also not subscribed to: branch or tag creation and deletion, forks, stars, watches, releases, repository settings changes, workflow runs, deployments, security advisories, or wiki edits.

What Enji Guard may write (where enabled)

Where you enable it, Enji Guard can:

• Open issues for findings and scheduled improvement work.
• Open pull requests and pull-request branches with proposed changes.
• Comment on issues and pull requests — for example, posting findings or results, or replying when the app is mentioned. Whether a comment is posted depends on the enabled audit or review workflow.

How GitHub tells us about events

Enji Guard is told when an issue, comment or pull request changes, rather than polling you. On GitHub this needs no webhook in your repository and no change to your settings: event subscriptions are a property of the GitHub App itself, and GitHub delivers them to the app for the repositories you installed it on. Nothing is written to your repository configuration.

This differs from GitLab, where Enji Guard does create webhooks in your project settings — see GitLab Access.

What Enji Guard does not do

• Merge pull requests. Not automatically, not on a setting — a person always merges.
• Deploy code.
• Write to branches you already have. Commits go only to branches we create for a change we are proposing, which then wait for your review.
• Audit, act on, or store content from repositories you have not connected — including the public ones GitHub grants read access to automatically, as described above. The access exists; we do not use it.
• Use repository access for unrelated accounts.
• Require a personal access token on GitHub — though a GitLab connection does use a token you create.

Revoking access

You can uninstall the GitHub App or change which repositories it can access at any time in your GitHub settings. Revoking access stops future use; reports and history already generated are handled as described in the Data Retention & Deletion page.