Connect Gatekeeper to the router

This page connects an installed Gatekeeper to the production router. Install it first. The commands are the ones the console prints under API Keys → How to connect; each block is badged, and this site's build fails if a block ever differs from the console.

1. Write a starter configuration

shfrom the consoleCopy
gatekeeper init

It creates confidential-gatekeeper/config.yaml inside your user configuration directory and fills it with the default policy. Where that is depends on the system: ~/.config on Linux, ~/Library/Application Support on macOS, %AppData% on Windows. Take the path from what the command prints, or ask for it later with gatekeeper config path. Nothing is contacted, and the file admits nothing until an endpoint has a pin.

The transcripts on this page were captured on Linux, so the paths in them are Linux paths.

gatekeeper initCopy
$ gatekeeper initWrote /home/you/.config/confidential-gatekeeper/config.yamlNext:  gatekeeper endpoint add <name> --listen 127.0.0.1:8443 --upstream https://<host>  gatekeeper endpoint trust add <name> --from-upstream  gatekeeper config validateA Swarm cloud needs no `trust roots add`: its certificate authority isaccepted on its own TEE evidence. Add one with `gatekeeper trust roots add`to pin a particular cloud, or to trust a CA that publishes no evidence.

2. Front the endpoint

shfrom the consoleCopy
gatekeeper endpoint add router --upstream https://api.router.superprotocol.com --listen 127.0.0.1:8787

The upstream is the router's API origin; 127.0.0.1:8787 is what your clients point at instead. Nothing is registered with the router at any point, and what Gatekeeper forwards is your client’s own request: its own headers are stripped and no forwarding headers are added, so no header reveals that a Gatekeeper is in the path.

gatekeeper endpoint addCopy
$ gatekeeper endpoint add router --upstream https://api.router.superprotocol.com --listen 127.0.0.1:8787Added endpoint "router" (127.0.0.1:8787 → https://api.router.superprotocol.com) to /home/you/.config/confidential-gatekeeper/config.yamlwarning: "router" has no pinned evidenceDigest and cannot admit traffic yet; pin one with `gatekeeper endpoint trust add router --from-upstream`

3. Pin what you are willing to trust

shfrom the consoleCopy
gatekeeper endpoint trust add router --from-upstream

--from-upstream is not trust-on-first-use. It verifies the endpoint first, prints the chain, the hardware report and the evidence digest it found, and pins only what you then confirm. What it does not check is whether the deployment is one you want; that is the question you answer with y.

The full report against production is on Install and send a verified request. The lines to read before confirming:

• Trusted root … attested (registry): the cloud's root was admitted on its own hardware evidence and a measurement Super Protocol signed.
• Observed TLS leaf equals Signed certFingerprint: the connection you are on is the one the proof describes.
• evidenceDigest: the deployment you are about to pin. Compare it with the digest the console's Overview shows.

Pass --yes to skip the question in a script; the report is still printed.

4. Run it

shfrom the consoleCopy
gatekeeper run

With a terminal, run opens a dashboard; --headless streams log lines instead. Gatekeeper verifies before it forwards, re-attests every 5 minutes, and refuses the request if any check fails. Point your OpenAI client at http://127.0.0.1:8787/v1: Connect a client.

Check the configuration

terminalCopy
$ gatekeeper config validate/home/you/.config/confidential-gatekeeper/config.yaml is valid and ready to run

What the four commands wrote, with the comments the starter file carries removed:

config.yamlCopy
version: 1trustedRoots: []defaults:  failMode: closed  reattestInterval: 5m  verdictCacheTtl: 60s  maxBundleAge: 24h  initialTimeout: 15sendpoints:  - name: router    listen: 127.0.0.1:8787    upstream: https://api.router.superprotocol.com    trustedEvidence:      - sha256:402198e23bc1bcd505a34d6cb28accd98f400e5444b0ca3a2d1e09d45ab72fc1log:  level: info  format: text

The whole sequence as one script, as the console's Copy the whole sequence button copies it:

The second line on macOS and Linux is not decoration: the installer runs in a child process and cannot change the PATH of the terminal you are in, so without it the next command is not found on any shell that does not already search the install directory, a stock macOS zsh among them. Windows needs no equivalent, because iex runs the script in your own session.

Code examples
macOS and LinuxWindows
shfrom the consoleCopy
curl -fsSL https://github.com/Super-Protocol/confidential-router/releases/latest/download/install.sh | shexport PATH="$HOME/.local/bin:$PATH"gatekeeper initgatekeeper endpoint add router --upstream https://api.router.superprotocol.com --listen 127.0.0.1:8787gatekeeper endpoint trust add router --from-upstreamgatekeeper run
PowerShellfrom the consoleCopy
irm https://github.com/Super-Protocol/confidential-router/releases/latest/download/install.ps1 | iexgatekeeper initgatekeeper endpoint add router --upstream https://api.router.superprotocol.com --listen 127.0.0.1:8787gatekeeper endpoint trust add router --from-upstreamgatekeeper run

When a digest changes

A redeploy of the router publishes a new evidence digest. Under the default policy Gatekeeper then denies at the policy stage and nothing is forwarded; that is a deployment you have not approved, not an error. Run gatekeeper endpoint discover router, read what changed, and pin the new digest with gatekeeper endpoint trust add router --from-upstream. The list of pins is plural so a rollout can be approved in advance: pin the new digest beside the old one, then unpin the old one with gatekeeper endpoint trust rm.