Understanding results

A Gate scan has three parts: what it found, what is wrong with it, and how bad that would be.

The whole output

gate scan

Gate v0.1.0

4 MCP servers
23 exposed tools
3 credentials

CRITICAL
GATE005  postgres.execute_query
         Agent can execute unrestricted SQL, against what looks like a
         production system.
         .mcp.json · mcpServers.postgres

HIGH
GATE009  filesystem
         Write access extends beyond the workspace to ~/Documents.
         .mcp.json · mcpServers.filesystem

────────────────────────────────────────────────────────────

1 critical
1 high

Blast radius: CRITICAL (84/100)

Why:
  + arbitrary SQL execution
  + production-looking credential in scope
  + destructive operations available

Explain any finding:  gate explain GATE005

The counts

4 MCP servers
23 exposed tools
3 credentials

This is the surface, before any judgement about it.

Name
MCP servers
Type
reachable systems
Description
Distinct servers configured across every file Gate read. A server declared in two editors is counted once.
Name
exposed tools
Type
callable actions
Description
Individual tools the agent can call. Gate enumerates these only when it recognises the exact package; for a server it does not recognise, it records a capability posture instead of inventing a tool list. That is why a scan can show 0 tools and still report a critical finding.
Name
credentials
Type
what it acts as
Description
Credentials the agent holds. Whether literal in the file or referenced from the environment. A referenced credential is good practice and is still counted, because the agent still has it.

The findings

Findings are grouped by severity, worst first, so the most serious ones are always at the top.

GATE005  postgres.execute_query
         Agent can execute unrestricted SQL, against what looks like a
         production system.
         .mcp.json · mcpServers.postgres

GATE005: a stable rule ID. Run gate explain GATE005 for the full reasoning, or visit usegate.dev/rules/GATE005.
postgres.execute_query: the subject: a tool, a server, or a file.
The sentence: what is wrong, in terms of what the agent can do.
The location: the file and the exact field, so you can go and fix it.

A finding marked NEW appeared since your baseline. In a pull request, that is usually the only line anybody needs to read.

The blast radius

Blast radius: CRITICAL (84/100)

Why:
  + arbitrary SQL execution
  + production-looking credential in scope
  + destructive operations available

This is the summary judgement: if this agent were wrong or compromised, how bad is it?

The number orders a level and lets the same repository be compared against itself over time. It is not a measurement of risk. The contributors are always listed, so you can see what produced a score instead of taking it on trust.

Read blast radius for the full model, including the escalation floors that override the arithmetic.

What to do first

In order:

Rotate anything under GATE001, GATE002 or GATE004. A credential in a file has already left your control. Assume it is compromised.
Read gate explain for each critical finding. Several of them describe a decision rather than a mistake. "your agent can drop tables" is not a bug, it is a choice somebody should make deliberately.
Narrow the widest thing. Filesystem scope is usually the cheapest large win: changing ~ to ./ in one argument often removes several findings and a whole blast-radius escalation.
Record a baseline and put it in CI. You will not fix everything today. A baseline means you do not have to, while still catching anything new.

gate scan --write-baseline

How blast radius is calculated Set up a baseline