DEV Community: JinHyuk Sung

Would you block a PR that changes GitHub Actions contents permission from read to write?

JinHyuk Sung — Tue, 30 Jun 2026 05:52:53 +0000

A sandbox PR changed one GitHub Actions workflow permission:

permissions:
  contents: write

The base branch had:

permissions:
  contents: read

That is the concrete case I am trying to calibrate.

Agent Gate reported:

Agent Gate: NEEDS HUMAN DECISION
Decision: warn
Why: contents permission increased from read to write.
Path: .github/workflows/demo-release.yml
Recommended next step: review the workflow permission change before merging.
Policy status: warning today; eligible to become a merge gate after tuning.

Rule: workflow/permission-escalation
Policy source: built-in default

Live PR comment proof:
https://github.com/sjh9714/agent-gate-install-smoke-20260617/pull/13#issuecomment-4828248162

What matters to me is that this did not depend on an LLM noticing the change.

The Action did not:

checkout PR code
run repository scripts
call an LLM at runtime
load policy from the PR head branch

The first-run repo config was also absent. Agent Gate used its built-in default policy and recorded:

configSource: default

I am not trying to claim that the PR is automatically bad. A permission increase can be intentional.

The question is what CI should do when it sees this kind of boundary change.

My current default is:

warn on first run
keep the report human-readable
let teams promote this finding to block after tuning

For AI-generated PRs, I think deterministic CI evidence is useful because agent changes can touch workflow and security boundaries as part of ordinary work.

But this specific finding is broader than AI: any PR that raises GitHub Actions permissions may deserve deliberate review.

Question:

In your repo, is this block, warn, or noise?

What extra evidence would make it actionable?

Repo:
https://github.com/sjh9714/Agent-Gate

Disclosure: I used AI assistance to help draft and edit this article, and I reviewed the technical claims before publishing.

I made Agent Gate installable in 30 seconds for AI PR checks

JinHyuk Sung — Fri, 26 Jun 2026 10:51:38 +0000

One problem with security-ish developer tools is that the install path can ask for trust before it has earned any.

Agent Gate is a GitHub Action for AI-generated pull requests. It does not review code with an LLM. It checks repeatable CI evidence such as workflow permission changes, agent control-plane drift, package lifecycle script drift, and missing test-file evidence.

The important constraint is that the Action should be safe to try first:

no checkout of PR code
no runtime LLM calls
no repository script execution
no policy loaded from the PR head branch
warn mode by default for first runs

I recently changed the onboarding flow so the first install is basically one pinned workflow download.

mkdir -p .github/workflows \
  && curl -fsSL https://raw.githubusercontent.com/sjh9714/Agent-Gate/v0.2.5/templates/agent-gate-observe.yml \
  -o .github/workflows/agent-gate.yml

This downloads a tag-pinned GitHub Actions workflow YAML file. It is not curl | bash, and it does not execute a remote script.

The downloaded workflow uses:

uses: sjh9714/Agent-Gate@v0.2.5
with:
  mode: warn
  fail-on-block: false

It also uses only:

permissions:
  contents: read
  pull-requests: read

The other change is that first runs no longer require agent-gate.yml.

If the default config file is confirmed missing on the PR base branch, Agent Gate uses its built-in default policy and records:

configSource: default

That means a maintainer can install the workflow first, see what the default warnings look like, and only add repo-specific policy later.

I also verified the README install path in a sandbox PR. The run:

loaded sjh9714/Agent-Gate@v0.2.5
used no actions/checkout
had no agent-gate.yml
fell back to the built-in default policy
finished successfully
produced a warn decision for package lifecycle script drift

The compact log looked like this:

Agent Gate: NEEDS HUMAN DECISION
Decision: warn
Why: preinstall script added in package.json.
Path: package.json
Policy status: warning today; eligible to become a merge gate after tuning.

- warn agf_2ac4687b2f8f712a dependency/lifecycle-script-added package.json

This is the first-run model I want:

install quickly
observe warnings
understand the report
then tune policy

It still does not prove semantic correctness. A deterministic CI gate should not pretend to know whether a PR is “good.” The goal is narrower: surface repeatable evidence that a maintainer can inspect before merge.

If you maintain a GitHub Actions-heavy repo or use coding agents to open PRs, I would like feedback on one thing:

Does this first-run path feel safe and clear enough to try in a real repo?

Repo:

https://github.com/sjh9714/Agent-Gate

CI gates for AI-generated PRs need re-derivable evidence

JinHyuk Sung — Sun, 21 Jun 2026 01:08:59 +0000

When a CI gate flags an AI-generated PR, the important question is not only "what did it flag?"

It is also:

"Could someone else come back later and re-derive why this finding fired?"

That is the reason I added evidence snapshots to Agent Gate v0.2.1.

What Agent Gate is

Agent Gate is a GitHub Action for AI-generated pull requests.

It does not review code with an LLM. It checks deterministic merge evidence in CI:

PR scope escapes
GitHub Actions permission escalation
AGENTS.md / .mcp.json drift
missing test-file evidence
high-risk path changes

The Action does not checkout PR code, call LLMs at runtime, or execute repository scripts.

Why finding IDs were not enough

In v0.2.0, Agent Gate added stable finding IDs.

That gave every finding a short audit handle, for example:

agf_987ab9ddb8c1b299

That is useful for references, comments, future override workflows, and log-based debugging.

But an ID by itself is not proof. If someone sees the ID later, they still need to know what recorded material produced it.

What v0.2.1 adds

v0.2.1 adds evidenceSnapshot to public findings.

The split is:

findingId = short audit handle
evidenceSnapshot = canonical material used to derive that handle

The snapshot is intentionally boring. It contains stable rule material such as:

rule id
severity
path or line when present
normalized evidence label/value pairs

It does not include timestamps, report order, risk score, version, commit SHA, or mutable display text.

A real report shape

Example compact log output:

Agent Gate: NEEDS HUMAN DECISION
Decision: warn
Risk score: 49 / 100
Why: Agent-generated PRs must include an agent-gate contract.
Recommended next step: Add a PR contract before relying on scope checks.
Policy status: warning today; eligible to become a merge gate after tuning.

Findings:
- error agf_be0c2c2a66312aff contract/missing
- error agf_987ab9ddb8c1b299 risk/high-risk-path .github/workflows/agent-gate.yml
- warn agf_6016e753491255d7 workflow/dangerous-pattern .github/workflows/agent-gate.yml

The compact log stays short, but the JSON and Markdown reports carry the fuller evidence.

Example JSON shape:

{
  "findingId": "agf_987ab9ddb8c1b299",
  "ruleId": "risk/high-risk-path",
  "severity": "error",
  "path": ".github/workflows/agent-gate.yml",
  "evidenceSnapshot": {
    "ruleId": "risk/high-risk-path",
    "severity": "error",
    "path": ".github/workflows/agent-gate.yml",
    "evidence": [
      {
        "label": "changed_file",
        "value": ".github/workflows/agent-gate.yml"
      }
    ]
  }
}

Why this matters

For me, the bar for promoting a finding from warning to blocking is:

A third party should be able to re-derive the finding from recorded evidence.

That does not mean the check is magically correct.

It means the failure mode is visible, reproducible, and tunable.

A repo can start in warn mode, observe which findings are useful, and only later promote low-noise findings into merge gates.

What this does not solve yet

Agent Gate still does not prove semantic correctness.

Matching test-file evidence is not proof that the tests cover the behavior. It is change evidence / self-consistency evidence.

Maintainer override storage is also not implemented yet. That is probably the next hard design question: if someone bypasses a finding, where should that override live so it is durable enough to inspect later?

CODEOWNERS / reviewer evidence and package dependency drift are also future work.

Try it

If you maintain a repo where coding agents open PRs, I would love feedback on whether this kind of evidence is useful or too noisy in observe mode.

Repo:

https://github.com/sjh9714/Agent-Gate

Disclosure: I maintain Agent Gate. v0.2.1 is still a prerelease; I would start in warn mode before treating any finding as a merge gate.

LLM reviewers are useful, but some PR checks should stay deterministic

JinHyuk Sung — Tue, 16 Jun 2026 20:17:27 +0000

AI coding agents are getting better at opening pull requests.

That changes the review problem.

A normal review asks whether the code looks correct, whether the design makes sense, and whether the edge cases were considered.

Those questions still matter.

But an AI-generated pull request also raises a different kind of question:

Did the agent change something outside the intended task, and is there enough repeatable evidence to merge?

I have started thinking about this as a split between judgment and evidence.

LLM reviewers help with judgment. Agent Gate verifies deterministic merge evidence.

I do not think every review question should become a hard CI gate. Some parts of code review need human context. Some parts benefit from an LLM noticing suspicious patterns. But a few checks are mechanical enough that I want them to be deterministic, repeatable, and visible before merge.

This is the checklist I currently use when thinking about AI-generated PRs.

1. Did the PR stay in scope?

The first question is not whether the code is good.

It is whether the PR changed the files it was supposed to change.

For a human PR, an unrelated edit may be easy to explain in review. For an agent PR, unrelated edits are more suspicious because they may reflect an instruction drift, a tool mistake, or a broad refactor the maintainer did not ask for.

A simple contract can help:

This PR is allowed to touch:
- src/auth/**
- tests/auth/**

Then the review can ask a deterministic question:

Did the PR touch anything outside those paths?

That does not prove the code is correct. It only proves the PR stayed inside its declared boundary.

That boundary still matters.

2. Did workflow permissions escalate?

GitHub Actions workflows are one of the highest-risk places for an agent to edit.

A small source change and a workflow permission change do not have the same risk profile.

For example, I would want a very visible warning if a PR adds or changes this:

permissions:
  contents: write

or starts using secrets.* in a new workflow path.

This is not a semantic code review problem. It is a policy boundary problem.

The question is deterministic:

Did this PR increase workflow privileges or introduce a dangerous workflow pattern?

That kind of check should not depend on whether an LLM happened to notice it in a comment.

3. Did agent-control-plane files change?

AI coding agents often depend on files that shape future behavior:

AGENTS.md
CLAUDE.md
.github/copilot-instructions.md
.cursor/rules/**
.mcp.json

A change to these files can affect future agent runs, tool access, or repo-specific instructions.

That makes them different from normal documentation changes.

If an AI-generated PR edits .mcp.json or AGENTS.md, I want that surfaced clearly before merge, even if the source code diff looks harmless.

The deterministic question is:

Did the PR change files that control future agent behavior?

This is especially important for teams adopting coding agents across repositories, because the control plane can drift quietly.

4. Is there matching test evidence?

Test evidence is tricky.

A changed test file does not prove the behavior is correct. It does not prove the test is meaningful. It does not prove coverage.

But for risky areas, the absence of any matching test change is still useful evidence.

If a PR changes auth logic, payment handling, session middleware, or a migration, I want to know whether the PR also changed a related test file.

The check should be phrased carefully:

There is no matching test-file evidence.

Not:

This PR is untested.

That distinction matters. Deterministic checks should say exactly what they know, and no more.

5. Did package scripts or dependencies drift?

This is not always the first rule I would add, but it is one I keep coming back to.

Package manifests and lockfiles can hide meaningful risk:

package.json
pnpm-lock.yaml
yarn.lock
package-lock.json

Some changes are normal dependency maintenance. Others deserve more attention:

{
  "scripts": {
    "postinstall": "node scripts/setup.js"
  }
}

For AI-generated PRs, I would want to know:

Did a lifecycle script appear?
Did an existing package script change?
Did dependencies change without an expected lockfile change?

Again, not every finding should block. But these changes should be easy to see.

6. Did the right human reviewer approve?

This is where deterministic evidence meets human ownership.

A PR can stay in scope, avoid workflow escalation, and include test evidence, but still need the right reviewer.

Examples:

src/auth/** changed -> security reviewer expected
.github/workflows/** changed -> platform reviewer expected
.mcp.json changed -> maintainer/platform approval expected

I do not think this should always block by default, especially for solo maintainers. But for teams, reviewer evidence may be one of the most useful signals.

The question is:

Did the right human approve the risky part of this PR?

That is not a replacement for review. It is a way to make ownership visible.

What should stay human?

A lot.

I would not want deterministic CI to answer questions like:

Is this design good?
Is this abstraction worth it?
Will users understand this behavior?
Is this bug fix actually correct?

Those are judgment questions.

LLM reviewers can help with judgment. Human reviewers own judgment. Deterministic gates should focus on evidence that can be checked the same way every time.

What should be deterministic?

The best candidates are checks that are:

explainable
repeatable
hard to miss
tied to merge risk
not dependent on executing PR code

For me, that currently includes:

PR scope boundaries
workflow permission escalation
dangerous workflow patterns
agent-control-plane drift
missing test-file evidence for high-risk paths
package script and dependency drift
reviewer evidence for sensitive paths

These checks do not make an AI-generated PR safe.

They make the risk easier to inspect before merge.

Start in warn mode

The safest adoption path is not to block everything on day one.

I would start with warnings:

mode: warn
fail-on-block: false

Then observe real PRs.

Which findings are useful?
Which ones are noisy?
Which ones would you trust as merge gates?

Only after that would I promote low-noise findings to blocking checks.

Closing thought

I think AI-generated PR review will need both judgment and evidence.

LLM reviewers can help with judgment.

Deterministic CI checks should verify merge evidence.

I’m exploring this idea in Agent Gate, a small GitHub Action for deterministic merge evidence in AI-generated PRs.

Disclosure: I used AI assistance to help draft and edit this article, and I reviewed the technical claims before publishing.

I built a deterministic CI firewall for AI-generated pull requests

JinHyuk Sung — Mon, 15 Jun 2026 15:22:57 +0000

AI coding agents are getting good enough to open pull requests.

That is useful.

It also changes the review problem.

A normal code review asks:

Does this code look correct?

An AI-generated PR also raises a different question:

Did this agent change something I did not intend, and does this PR have enough evidence to merge?

Agent Gate is still a prerelease, so I am starting with a narrow goal: make AI-generated PRs easier to inspect before merge.

That second question is why I built Agent Gate for AI PRs.

The core idea

Agent Gate is a deterministic CI firewall for AI-generated pull requests.

It is not an LLM reviewer.

That distinction matters.

LLM reviewers help with judgment. Agent Gate verifies deterministic merge evidence.

An LLM reviewer can tell you whether code looks suspicious. Agent Gate checks whether the PR crossed policy boundaries that should be explainable and repeatable in CI.

The mental model is:

Use your LLM reviewer for judgment.

Use Agent Gate for deterministic merge evidence.

Agent Gate checks questions that should not require an LLM:

did the PR stay inside its declared scope?
did workflow permissions escalate?
did agent control-plane files drift?
did high-risk code change without matching test-file evidence?
did MCP config changes get surfaced?

These are not semantic code review questions. They are merge-boundary questions.

Why I wanted this

Imagine an agent is asked to fix an auth session bug.

The expected scope might be:

allowed_paths:
  - src/auth/**
  - tests/auth/**

But the PR also changes:

src/payments/webhook.ts
.github/workflows/release.yml
.mcp.json

A reviewer might catch that. An LLM reviewer might catch that. But I do not want this to depend only on someone noticing.

I want CI to say:

This PR crossed its declared scope.
This PR changed workflow permissions.
This PR changed the agent tool surface.
This PR needs human decision before merge.

That is the shape of Agent Gate.

What Agent Gate catches today

The current v0.1.2 release is intentionally focused on deterministic checks.

It can flag or block the following, depending on policy mode.

Out-of-contract edits

Agent Gate can parse a small PR body contract:

<!-- agent-gate-contract
version: 1
agent: codex
task: update auth session handling
allowed_paths:
  - src/auth/**
  - tests/auth/**
required_evidence:
  - matching auth tests changed
-->

If the PR changes files outside allowed_paths, Agent Gate reports that as a contract escape.

Workflow permission escalation

GitHub Actions workflows are powerful. If a PR changes this:

permissions:
  contents: read

to this:

permissions:
  contents: write

that should be visible before merge.

Agent Gate checks workflow-level permission escalation and dangerous workflow patterns such as:

write-all
id-token: write
pull_request_target checking out PR head
unpinned third-party actions
added secrets.* usage

Agent control-plane drift

Files like these can change how future agents behave:

AGENTS.md
CLAUDE.md
.cursor/**
.github/copilot-instructions.md
.mcp.json

A PR that changes .mcp.json is not just changing config. It may be changing which tools an agent can call.

Agent Gate treats those files as an agent control plane and reports drift.

Missing test evidence

Agent Gate can define high-risk paths:

high_risk_paths:
  auth:
    paths:
      - src/auth/**
    require_tests:
      - tests/auth/**
    severity: error

If auth code changes but no matching auth test file changes, Agent Gate reports missing test evidence.

This does not prove semantic test coverage. It only checks deterministic file-pattern evidence.

That limitation is intentional.

What a report looks like

One piece of early feedback was that the report should not start with a wall of rule IDs.

It should answer the maintainer's first question:

What should I do with this PR?

So the Markdown report now leads with a human decision.

Example shape:

Agent Gate: NEEDS HUMAN DECISION

Why:
This PR changed `.github/workflows/release.yml` and added `secrets.*` usage.

Recommended next step:
Review the workflow change before merging.

Policy status:
Warning today; eligible to become a merge gate after tuning.

The detailed rule findings still appear underneath.

The machine-readable JSON decision remains simple:

{
  "decision": "warn"
}

The human-facing report can say NEEDS HUMAN DECISION, while the machine-readable result stays pass, warn, or block.

The trust boundary

Agent Gate is designed around a conservative trust boundary.

At runtime, the GitHub Action:

does not checkout PR code
does not execute repository scripts
does not call LLMs
does not execute MCP servers
does not load policy from the PR head branch

It reads PR metadata and changed-file contents through GitHub APIs.

It loads agent-gate.yml from the PR base branch, not from the untrusted PR branch.

That matters because a PR should not be able to weaken its own policy.

Installing it

Agent Gate is available on GitHub Marketplace:

https://github.com/marketplace/actions/agent-gate-for-ai-prs

A minimal workflow looks like this:

name: Agent Gate

on:
  pull_request:
    types:
      - opened
      - synchronize
      - reopened
      - edited
      - labeled
      - unlabeled
      - ready_for_review

permissions:
  contents: read
  pull-requests: read

jobs:
  agent-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: sjh9714/Agent-Gate@v0.1.2
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          mode: warn
          fail-on-block: false

I recommend starting with:

mode: warn
fail-on-block: false

That gives you an observe path.

First learn what Agent Gate finds in your repository. Then promote only the policies that are useful and low-noise into merge gates.

A small starting policy could be:

version: 1
mode: warn

contract:
  required_for:
    - agent
  allow_missing_in_observe_mode: true

agent_detection:
  labels:
    - ai
    - agent
    - codex
  branch_patterns:
    - "codex/**"
    - "ai/**"

high_risk_paths:
  workflows:
    paths:
      - ".github/workflows/**"
    severity: error

Local replay demo

The repository includes an unsafe-pr-zoo with deterministic fixtures.

After cloning the repo and installing dependencies, you can run:

pnpm install
pnpm --filter agent-gate build
node packages/cli/dist/main.js replay fixtures/unsafe-pr-zoo/workflow-permission-escalation

Example output:

Agent Gate: BLOCKED

ERROR workflow/permission-escalation
contents permission increased from read to write.
Path: .github/workflows/release.yml

ERROR workflow/dangerous-pattern
.github/workflows/release.yml contains a dangerous GitHub Actions workflow pattern.
Path: .github/workflows/release.yml

Other fixtures cover:

agent control-plane drift
out-of-scope agent edits
missing test evidence
MCP config drift

What Agent Gate is not

Agent Gate is not a replacement for code review.

It does not try to find every semantic bug.

It does not know whether a function is logically correct.

It does not prove that tests are sufficient.

It does not replace a human reviewer, an LLM reviewer, or normal CI.

It answers a narrower question:

Did this PR cross deterministic policy boundaries before merge?

That is the problem I want it to solve well.

Current limitations

v0.1.2 is still a prerelease.

Known limitations:

APIs, rule names, reports, and config may change.
CODEOWNERS and reviewer evidence are not implemented yet.
Package and dependency drift rules are not implemented yet.
GitHub Actions job-level permission escalation comparison is limited.
Test evidence is file-pattern based and does not prove semantic coverage.
PR comment upsert requires issues: write and can warn on fork PRs with read-only tokens.

What I want feedback on

I am especially interested in feedback from people trying AI-generated PRs in real repositories.

The main questions:

Which findings should block by default?
Which findings should stay warning-only?
What high-risk path patterns do you use?
Would CODEOWNERS or reviewer evidence make this more useful?
Should package script and dependency drift be part of the gate?
What would make this too noisy to adopt?

Feedback issue:

https://github.com/sjh9714/Agent-Gate/issues/27

Repository:

https://github.com/sjh9714/Agent-Gate

Closing thought

LLM reviewers are useful.

But if AI-generated PRs become part of normal engineering workflows, teams will also need deterministic gates.

Not every review question should be probabilistic.

Some questions are simple:

Did this PR stay within scope?

Did workflow permissions escalate?

Did agent control-plane files change?

Is there matching test evidence?

That is the space Agent Gate is trying to explore.

Use your LLM reviewer for judgment.

Use Agent Gate for deterministic merge evidence.

Disclosure: I used AI assistance to help draft and edit this article, and I reviewed the technical claims before publishing.

Auditing GitHub CLI extensions before installing more

JinHyuk Sung — Thu, 11 Jun 2026 09:50:21 +0000

GitHub CLI extensions are useful, but extension discovery has a small practical problem: it is easy to find more extensions before you understand whether your current setup already covers the workflows you care about.

I built a small browser-only audit page for that problem:

https://sjh9714.github.io/gh-extension-atlas/audit.html?demo=1

It opens with a sample result loaded. If you want to check your own setup, run:

gh extension list

Then paste the output into the page.

The audit runs locally in the browser. There is no sign-in, no analytics script, and no remote audit API. The pasted extension list is not uploaded.

What the audit checks

The page compares installed GitHub CLI extensions against the GitHub CLI Extension Atlas catalog:

https://github.com/sjh9714/gh-extension-atlas

It shows:

installed extensions that are already reviewed in the atlas
installed extensions that are not listed yet
missing Top Picks
workflow coverage gaps
copyable install commands for missing workflow recommendations

The goal is not to install every recommended extension. The goal is to make the next install decision smaller and easier to review.

Why not just use `gh extension search`?

gh extension search is useful when you already know what you are looking for.

It is less useful when the question is:

Which terminal dashboard should I try first?
Do I need a notification tool if I already use a broader dashboard?
Which extension is for GitHub Actions operations versus workflow statistics?
Is this branch cleanup tool the right fit for my risk tolerance?

Those are comparison questions, not search questions.

The atlas tries to answer them with a reviewed catalog, Top Picks, comparison guides, and workflow recommendations.

A few examples

For daily GitHub triage, the atlas points to gh-dash first because it covers PRs, issues, and notifications in one terminal dashboard.

For GitHub Actions, it separates different jobs:

gh-enhance for an interactive Actions TUI
gh-workflow-stats for success rate and duration summaries
gh-act for local workflow runs
gh-actions-importer for migration work

For branch cleanup, it compares tools like gh-poi, gh-branch, gh-clean-branches, gh-tidy, and gh-worktree because they sound related but solve different habits and risk profiles.

The data contract

The catalog is also available as JSON:

https://sjh9714.github.io/gh-extension-atlas/api/extensions.json

Each entry includes fields such as:

repository
category
install command
best-fit use case
avoid-if note
license
archived status
maintenance status
verification date

That makes it usable by scripts, documentation tools, or coding agents that need current extension metadata instead of stale memory.

What feedback would help

I am mainly looking for factual corrections and missing-extension suggestions:

inaccurate descriptions
wrong categories
misleading maintenance labels
better comparisons between overlapping tools
useful GitHub CLI extensions that are missing from the catalog

If you maintain a GitHub CLI extension and the atlas describes it poorly, a short correction is enough.

Note: I used AI assistance while organizing the launch plan and editing this post, but the project metadata, examples, and claims were reviewed before publishing.

DEV Community: JinHyuk Sung

Would you block a PR that changes GitHub Actions contents permission from read to write?

I made Agent Gate installable in 30 seconds for AI PR checks

CI gates for AI-generated PRs need re-derivable evidence

What Agent Gate is

Why finding IDs were not enough

What v0.2.1 adds

A real report shape

Why this matters

What this does not solve yet

Try it

LLM reviewers are useful, but some PR checks should stay deterministic

1. Did the PR stay in scope?

2. Did workflow permissions escalate?

3. Did agent-control-plane files change?

4. Is there matching test evidence?

5. Did package scripts or dependencies drift?

6. Did the right human reviewer approve?

What should stay human?

What should be deterministic?

Start in warn mode

Closing thought

I built a deterministic CI firewall for AI-generated pull requests

The core idea

Why I wanted this

What Agent Gate catches today

Out-of-contract edits

Workflow permission escalation

Agent control-plane drift

Missing test evidence

What a report looks like

The trust boundary

Installing it

Local replay demo

What Agent Gate is not

Current limitations

What I want feedback on

Closing thought

Auditing GitHub CLI extensions before installing more

What the audit checks

Why not just use gh extension search?

A few examples

The data contract

What feedback would help

Why not just use `gh extension search`?