---
title: "KYE™ GitHub App™ — governed authority checks at pull-request time · KYE Protocol™"
description: "KYE™ GitHub App™ runs a governed authority check on every pull request. When a PR touches a privileged change, it asks the KYE Protocol™ Policy Decision Point whether the change carries the required authority and evidence, then posts a governed Check Run with a replay-provable evidence link."
url: https://kyeprotocol.com/github-app/
lang: en
source: "KYE Protocol"
---

> KYE™ GitHub App™ runs a governed authority check on every pull request. When a PR touches a privileged change, it asks the KYE Protocol™ Policy Decision Point whether the change carries the required authority and evidence, then posts a governed Check Run with a replay-provable evidence link.

# Governed authority checks, right at pull-request time

When a pull request changes something privileged — a deploy workflow, a data schema, an agent's runtime — the **KYE™ GitHub App™** asks one question before it can merge: does this change carry the _authority_ and _evidence_ it needs? It posts the answer as a governed Check Run, with a replay-provable evidence link a reviewer or auditor can verify later.

The result: instead of reconstructing who authorised a risky change after an incident, your team sees the governed verdict on the PR itself — cutting change-review evidence-gathering from hours to a single click.

[Start a governed pilot](https://kyeprotocol.com/poc/) [See KYE™ Lens™](https://kyeprotocol.com/kye-lens/)

## One question, asked at the right moment

The hard part is never the code review — it is proving the change was authorised. The KYE™ GitHub App™ moves that proof to the moment the change is proposed.

- It runs on the pull-request events GitHub already emits — `pull_request` and `check_run` — with no extra CI wiring.
- It detects privileged changes (deploy workflows, data schemas, runtime engines, secret or migration markers) and only governs those — ordinary docs PRs pass untouched.
- It maps the verdict to a standard GitHub Check Run, so it sits beside your existing required checks.

## It asks KYE Protocol™ — it does not invent the answer

The KYE™ GitHub App™ never decides on its own. It sends the change to the same KYE Protocol™ decision engine that governs every action across the platform, and emits the standard governance evidence chain for each verdict — the same chain that makes a decision replay-provable from public keys alone.

### Success

The change carries the required authority and evidence. The Check Run passes.

### Neutral

Allowed with obligations. The summary lists what the change must satisfy.

### Action required

A human sign-off — for example two-person approval — is needed before merge.

### Failure

The privileged change lacks the required authority or evidence. It must not merge as-is.

Each verdict carries a §0.3 evidence link — a decision id and [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) reference a reviewer can replay-verify later, aligned with the audit-trail expectations of the EU AI Act™ (Article 12 record-keeping) and ISO/IEC 42001. It is part of the [KYE Protocol™](https://kyeprotocol.com/) platform.

## Install

Installation grants the KYE™ GitHub App™ two scopes — read your pull requests, and write Check Runs — and nothing more. It reads only the pull-request metadata GitHub sends it; it does not clone your code or store your source.

- Install on a single repository to start, then widen to an organisation once you have seen the governed verdicts.
- Point it at your KYE Protocol™ decision endpoint; verdicts and their evidence appear on every privileged PR.
- Review the governed checks, the obligations, and the evidence links from your usual GitHub review surface.

[Start a governed pilot](https://kyeprotocol.com/poc/)