Read a verdict · Confidential Router

Discover what an endpoint publishes, verify it once, read a running Gatekeeper's status, and understand a denial.

Three commands look without forwarding anything. All three take --json. The transcripts below were captured on Linux; the configuration path yours prints depends on your system, and gatekeeper config path names it.

Look before you pin

endpoint discover verifies and prints the evidence, and never writes to the configuration. It takes a configured endpoint name or a bare hostname.

sh
gatekeeper endpoint discover router

Against production, with no pin yet, it ends with DENIED — verified, but policy: the built-in pin policy (gatekeeper.default) denied and the line to act on:

terminal
To accept this deployment:  gatekeeper endpoint trust add router sha256:402198e23bc1bcd505a34d6cb28accd98f400e5444b0ca3a2d1e09d45ab72fc1

"Verified, but" is the important phrase: every cryptographic stage passed, and only the pin is missing.

Verify once

verify runs the whole pipeline against a live host and evaluates every policy. Exit status 0 means the endpoint would be admitted; 3 means it would not.

gatekeeper verify router, after pinning, 2026-10-12
$ gatekeeper verify routerADMITTED — verified and allowed by every policyEndpoint       routerUpstream       https://api.router.superprotocol.comChecked        1s agoEvidence kind  DeploymentEvidenceIssued         7s agoTrusted root            attested:5690b13a922698ece1e9b64512910b58f1d60e338ff1d9e16f26cf631cdf409a (sha256:611bfbb75fa0adceb86128072e557c7defb5457e12d87173d57a3ea7d84ccefe) — attested (registry), not from trustedRootsObserved TLS leaf       sha256:ce86d54e9e7275ce4132d7798d5fb18467dbe9a436178199f8441d240a8ef8ebSigned certFingerprint  sha256:ce86d54e9e7275ce4132d7798d5fb18467dbe9a436178199f8441d240a8ef8ebevidenceDigest            sha256:402198e23bc1bcd505a34d6cb28accd98f400e5444b0ca3a2d1e09d45ab72fc1Pinned for this endpoint  yesRoot certificate TEE evidence  Verdict             attested (registry) — this is a Super Swarm root  Evidence type       Intel TDX (Azure)  Report integrity    ok  Chain revocation    not checked  Debug mode          disabled  Ciphertext hiding   disabled  Page swap disabled  disabled  Network type        trusted  Measurement         5690b13a922698ece1e9b64512910b58f1d60e338ff1d9e16f26cf631cdf409a (in trusted registry)  Key binding         0e9652758883907a520eb516b9bb26276f7495c4ba95b1d1cde3e63009d90fef (matches the report data)Certificate chain (leaf → root)  ROLE  SUBJECT                                                                                 FINGERPRINT             EXPIRES  leaf  CN=Super Swarm Evidence Subroot CA Level 1,OU=IT,O=SuperProtocol,L=New York,ST=NY,C=US  sha256:e79e0c6f…e7b79d  2027-01-09  root  CN=Super Swarm Root CA,OU=IT,O=SuperProtocol,L=New York,ST=NY,C=US                      sha256:611bfbb7…4ccefe  2036-10-08Container images  docker.io/library/busybox@sha256:5cec3fc171c87218698e85a52af7087de727372aae264a787b8112901a5b0092  docker.io/library/haproxy@sha256:56b887da77428b7a6621e59e480cdbd330cc805c22d3cedb66ceea76ffdea2c6  ghcr.io/super-protocol/confidential-router/gatekeeper@sha256:56158ed17a2f7f9124d30215472ea0fe2ac3dc56974eb0e6808ba0aced11e7d8  ghcr.io/super-protocol/confidential-router/router-api@sha256:3e1600b0b820bf0a048582c2f8e403a06e991873e38348c8278508416b346954  ghcr.io/super-protocol/confidential-router/router-ui@sha256:fdd529f1751de8dcdc10821a54cff328e8d88915d6523c1ff3dc39359056a503  ghcr.io/zalando/spilo-17@sha256:b7db9e8f62e809ebd9a0679fbdba147a811fdd240ab78380ea4720a46a017184  quay.io/coreos/etcd@sha256:2c029095680c13c2b36116cc3935e1b0cddc0f5af78004457fd863616d8d072bPolicies  POLICY      PACKAGE             RESULT  (built-in)  gatekeeper.default  allow

Reading the report

Line	Meaning
`Trusted root … attested (registry), not from trustedRoots`	The root was admitted on its own hardware evidence and a registry-signed measurement, not from a certificate you pasted
`Observed TLS leaf` and `Signed certFingerprint`	Equal: the connection is the one the proof describes
`evidenceDigest` and `Pinned for this endpoint`	The deployment, and whether you approved it
`Verdict … attested (registry)`	The root's own TEE evidence verified; `attested (operator-pinned)` would mean you accepted the measurement yourself
`Report integrity ok`	The hardware report chains to the CPU vendor
`Chain revocation not checked`	Vendor revocation lists are an opt-in (`attestedRoots.checkRevocations`)
`Debug mode`, `Ciphertext hiding`, `Page swap disabled`	TEE flags, reported and never enforced; require what you want in a policy
`Network type trusted`	The platform's own network split, as declared by the root
`Measurement … (in trusted registry)`	The rebuilt launch measurement carries a Super Protocol signature
`Key binding … (matches the report data)`	The report commits to this certificate's key
`Container images`	Every image in the pinned snapshot, by digest

A verify of a hostname that is not configured has no pins, so it can be verified but never admitted.

Status of a running Gatekeeper

status asks the running process for every endpoint: whether its listener is up, its last verdict, and how much traffic it carries. It reports; it does not verify. It needs the admin socket:

terminal
$ gatekeeper statusgatekeeper: a running gatekeeper is only reachable through its admin socket, and none is configured       (add an `admin:` section to /home/you/.config/confidential-gatekeeper/config.yaml, or read the dashboard `gatekeeper run` already shows)

Add it and reload:

yaml
admin:  listen: unix:/run/user/1000/gatekeeper.sock

Every response through a running Gatekeeper also carries the header X-Gatekeeper-Verdict, allow on an admitted connection.

What a denial says

A request that arrives while there is no valid verdict is answered by Gatekeeper itself, under the default failMode: closed. Nothing reaches the upstream, and any connection the previous verdict admitted is closed.

HTTP 503
{  "error": {    "message": "policy: the built-in pin policy (gatekeeper.default) denied",    "type": "gatekeeper_error",    "code": "attestation_failed"  },  "stage": "policy",  "reason": "the built-in pin policy (gatekeeper.default) denied"}

error is OpenAI-shaped so a client library surfaces the message. stage names the check that failed; the table is on Vocabulary. The same string is on the X-Gatekeeper-Verdict header.

The denial you are most likely to meet is policy with an unpinned or changed digest: a deployment you have not approved. The one that means "not a build the registry signed" names the measurement and points at Test or unsigned builds.

When a newly signed cloud is admitted

A running Gatekeeper caches the attested-root verdict for 10 minutes (attestedRoots.cacheTtl) and re-attests every endpoint on its own schedule (5 minutes by default). A cloud whose measurement is signed later is admitted within about 15 minutes without a restart, or at once on SIGHUP.