Skip to content

No Fourgate cloud, no database, no telemetry.

So there are no sub-processors and nothing for us to leak. Limited beta 0.4.0b1 runs on your machines (a laptop, a server, or CI you operate) and nothing is sent to Fourgate. Supported use is local command-configured stdio. Customer CI, the Desktop UI, and production reliability are unvalidated. There is no remote MCP transport and no hosted control plane. This page is written for whoever reviews Fourgate for security. It follows PILOT.md and SECURITY.md.

  1. tools/call

  2. fourgate guard

    Local process on your machine. Forwards the call unchanged, then extracts only the contracted fields (e.g. record ID, title) from a success result.

    Stores

    • Runtime contract: tool names, which fields to extract, the verifier command, environment variable names

    Never contains

    • Credentials
    • Customer data

    unchanged

  3. its own calls

  4. read back by the verifier: HTTPS GET, read-only credential

  6. structure only

  7. local HTML

The same diagram as written in PILOT.md
 Your agent (e.g. an MCP client)
        │  tools/call
        ▼
 fourgate guard  ── local process on your machine ──────────────────────┐
        │  forwards the call unchanged                                  │
        ▼                                                               │
 Your MCP server  ──(its own API calls, as today)──►  Your system of record
        │  "success" result                                             ▲
        ▼                                                               │
 guard extracts only the contracted fields (e.g. record ID, title)      │
        │                                                               │
        └─► verifier (local)  ── HTTPS GET with a separate read-only ───┘
                 │               credential
                 ▼
         PASS / FAIL / UNKNOWN  ──►  outcomes.jsonl (local, structure only)
                                            │
                                            ▼
                               fourgate summary  ──►  local HTML page

Authentication is local credential routing—not a Fourgate login.

Fourgate has no user accounts, sessions, API keys or hosted authentication service. Authentication happens only between software you run and the APIs you already use. The website is a static export and does not receive, exchange or store those credentials.

Write path

Your MCP server authenticates to the target API with its existing write credential. Fourgate forwards the tools/call unchanged and does not copy that credential into a contract.

fourgate/scan.py

Verification path

The local verifier independently authenticates an HTTPS GET with a separate, least-privilege read credential. Its value is resolved from the named environment variable only when the check runs.

fourgate/readback.py

Isolation boundary

Names listed in verifier.secret_env are removed from the wrapped MCP server environment. The verifier remains local and receives the operator environment, so verifier commands must be trusted.

wrap/wrap.py

Request flow

  1. 1The agent sends tools/call to fourgate guard over local stdio.
  2. 2Guard records the request ID and contracted arguments, then forwards the call to the MCP server.
  3. 3The MCP server uses its own write credential to call the system of record and returns its MCP result.
  4. 4Guard extracts only contract-approved fields and starts the local verifier.
  5. 5The verifier reads the separate credential from its environment and sends a bounded GET to the configured static host.
  6. 6The authoritative response becomes PASS, FAIL or UNKNOWN; only a confirmed FAIL changes the agent-visible result in enforce mode.

How the read token is sent

Config stores an environment-variable name, never the token value. Bearer is the default; a custom header or Basic auth can be selected explicitly.

{
  "type": "http",
  "url_template": "https://api.example.com/issues/{record_id}",
  "token_env": "READBACK_TOKEN",
  "auth": { "scheme": "bearer" }
}
  • bearer sends Authorization: Bearer ….
  • header sends the token in one configured header, with an optional prefix.
  • basic supports an environment-supplied username and uses the token as password, or the inverse.
  • No token is sent when token_env is omitted.

Every file Fourgate writes, and what it never contains.

Fourgate keeps no other state. To uninstall, run pip uninstall fourgate, point your MCP client back at the original server command, and delete these files.

  • Runtime contract

    runtime.jsonWhere: Your machine or repo

    Contains

    Tool names, which fields to extract, the verifier command, environment variable names

    Never contains

    Credentials, customer data

  • Read-back config

    readback.jsonWhere: Your machine or repo

    Contains

    The GET URL template, expected fields, status rules, the environment variable name of the read token

    Never contains

    The token itself

  • Outcome log

    outcomes.jsonlWhere: Path you choose

    Contains

    Per protected call: time, server label, tool name, mode, PASS/FAIL/UNKNOWN, reason code, names of checked fields, time the check added

    Never contains

    Arguments, field values, record IDs, response bodies, credentials

  • Summary page

    fourgate-summary.htmlWhere: Path you choose

    Contains

    Counts and charts built from the outcome log

    Never contains

    Same exclusions as the log; no JavaScript, no network requests

  • Scan reports (optional)

    fourgate-report.json / .htmlWhere: Only if you pass --report-dir

    Contains

    For test-account scans: the contracted request, tool response and read-back evidence for non-passing cases, after best-effort secret redaction

    Never contains

    Redaction is best effort: review before sharing

Credentials, read-back safety and failure behavior.

  • The MCP server keeps its own write credential, exactly as today.
  • The verifier uses a separate, read-only credential that you create. Both are environment variables you set; contracts, logs and the summary contain only the variable names.
  • List the read credential in verifier.secret_env and fourgate guard removes it from the MCP server's environment, so the server under test cannot see or use it.
  • The verifier itself inherits the full operator environment, so only trusted verifier commands belong in contracts.
  • Fourgate never stores credentials.

Audit it yourself.

Fourgate is MIT licensed. Read the code, read the security notes, and check the release files against the SHA-256 digests GitHub lists on the release page.

Compare with the digest on the release page

  1. sha256sum fourgate-0.4.0b1-py3-none-any.whl
Illustration with placeholder digests= match

Reviewing Fourgate for your team?

We can walk your security reviewer through the data flow on the scope call.

Book a 30-minute scope call (opens in a new tab)Email us