EXPERIMENT_034 // ZERO-TRUST.AGENT.GATEWAY
Watch three mock agents present simulated identities to a gateway that checks each one, routes routine actions straight through, and blocks sensitive actions until you personally approve or deny them — while an agent with an expired or unregistered identity is rejected before its requested action is even read.
LOADING EXPERIMENT...
Three mock agents send nine tool-call requests through a gateway, one at a time. Each request first has its simulated identity checked; an expired or unregistered identity is rejected on the spot, regardless of what the request was trying to do. Only a verified identity reaches the policy stage, where routine actions pass automatically and sensitive ones stop and wait for you to click Approve or Deny. Deny a gated request and any later request that depended on it is visibly skipped rather than quietly running anyway.
HOW IT WORKS
A scripted fixture file carries nine tool-call requests from three mock agents — two hold currently-valid simulated identities, a third's identity has expired, and a fourth request is a straightforward impersonation attempt from an agent id the gateway has never registered. No LLM call and no real tool execution back this demo, so the same run produces the same verdicts every time.
`runGateway()` is a small, three-stage pure function. Stage one checks the request's simulated identity against a fixed registry and a fixed clock; if it fails, stage two — the policy check — never runs at all. Only a verified identity reaches the policy stage, where a routine action is allowed and a sensitive one is flagged. The gate stage then routes the outcome: auto-pass, block for approval, or reject.
An identity rejection and a visitor's denial are both "no", but they mean different things and render differently: a rejected identity never reaches the policy stage at all — its policy row shows "not evaluated" and its card carries a dashed border — while a denied request shows the full pipeline, including the sensitive-action verdict you were the one who turned down.
When a request needs approval, the scenario stops and waits — nothing advances until you click Approve or Deny. Denying a request that a later request depends on doesn't just skip a line of copy: that later request never reaches its own gate at all, and renders as skipped with the reason shown, not silently dropped.
WHAT THIS PROVES
Identity-before-authorisation is easy to state and easy to skip in practice. Making the gateway's verify-then-policy pipeline a visitor can click through — where a rejected identity visibly never reaches the policy stage, action untouched — turns a design principle from the "Every Agent Needs a Passport" article into something a browser tab can demonstrate in under a minute, with the short-circuit itself the thing on screen.
It's the runtime counterpart to Labs' two static-audit linters: the Agent Permission Linter and the ASI-Checklist Linter both score a configuration file once, offline, before anything runs. This experiment gates individual, live tool-call requests one at a time instead — the scenario neither linter can rehearse, and the reason a zero-trust gateway is a different mechanism from a pre-flight checklist, not a fancier version of the same one.