Pull requests

Gate's output routinely ends up in a public pull request log. That constraint shaped what it says.

The job summary

The GitHub Action writes a job summary on every run:

Gate

Blast radius: 🔴 CRITICAL (84/100)

arbitrary SQL execution

production-looking credential in scope

destructive operations available

4 MCP servers · 23 tools · 3 credentials

[!WARNING] This change increases the agent's blast radius. New capabilities: execute, delete

Rule Where Finding
🔴 GATE005 NEW .mcp.json postgres.execute_query can execute arbitrary commands or queries.

	Rule	Where	Finding
🔴	GATE005 NEW	`.mcp.json`	postgres.execute_query can execute arbitrary commands or queries.

The one-line verdict

Most security tooling in a pull request says some version of "there are 47 issues". Reviewers learn to scroll past it.

Gate leads with the one thing that is genuinely new information:

This change increases the agent's blast radius.

That is a claim Gate can justify, because it can name the capability that appeared and point at the line that added it. It is also a claim that changes what a reviewer does. Nobody merges a diff that hands an agent the ability to delete production data once somebody has said so out loud.

What is safe to publish

Everything Gate writes to a pull request is safe in a public log:

Rule IDs, counts and severities. No content.
File paths and field paths. mcpServers.github.env.GITHUB_TOKEN tells you where to look without telling anyone what is there.
Redaction placeholders. Never a value, never a prefix, never a suffix.

Gate's JSON output path re-scans its own output for credential shapes before printing and refuses to emit anything that matches. See secret handling.

The action uploads nothing. The scan result stays in the workspace.

Reviewing a Gate finding

Three questions, in order:

Is it new? A finding without NEW was already true before this branch. It may still need fixing, but not necessarily by this author, in this pull request.
Is the capability intended? Several Gate findings describe a decision rather than a mistake. "This agent can drop tables" is not a bug. It is a choice, and the review is where it should be made.
If intended, is it recorded? Update the baseline in the same pull request, or add an ignore entry with a reason. Both leave a trail; neither is silent.