Technical note · AI agents · Delegation

A valid signature is not live authority.

A cryptographically valid token can outlive the delegated permission that justified it. Here is why agent tool servers must distinguish token validity from current authority.

Watch a live authority decision change.

Actual GATE sandbox HTTP calls · no login · synthetic graph

Run live demo →

What a signature can — and cannot — prove

Imagine an agent carrying a signed delegated credential to export a customer's records. The user revokes that delegation in an upstream system. The credential may still have a valid signature, audience and expiry. None of those facts alone proves that the upstream grant is still active.

Credential verification asks whether the token is authentic and its claims are well formed. Live delegated-authority verification asks whether an eligible delegation path from principal to actor still exists at the moment of action.

OAuth introspection, short-lived tokens, revocation mechanisms and existing policy engines already solve important parts of this. GATE is not a replacement for them; it is an experiment in making the cross-domain authority-state check composable.

Why alternate paths matter

                              ┌── Department A ───┐
Human principal ──────────────┤                   ├── Agent C ── Tool
                              └── Department B ───┘

With both paths active, GATE returns VALID / ALLOW. Revoking A alone should not discard B's independent delegation: the result remains VALID / ALLOW. After B is revoked, there is no surviving known path, so the result becomes INVALID / DENY.

If authority state cannot be established with the requested freshness, GATE returns UNKNOWN / DENY. The host application still must authenticate the actor and enforce all business and resource policies; GATE's ALLOW is not complete authorization.

Reproduce it yourself

The hosted two-minute demo uses genuine HTTP requests to the Supabase-hosted GATE sandbox. Its graph is deliberately synthetic. The sandbox's revoke endpoint is an administrative demo operation, not a cryptographically signed event from a third-party issuer.

For signed authority events, the separate live ES256 integration reference lets you use a disposable GATE Free project, register a P-256 public key, submit signed ACTIVE and REVOKED events, and verify the result. This reference generates a local signer; connecting a genuine independent third-party authority source is a separate validation task.

Freshness and partitions are not magic

A disconnected replica cannot instantly learn a revocation that never arrived. Cryptographic checkpoints and bounded freshness can constrain risk, but cannot eliminate network partitions.

GATE v7 currently uses one Canadian PostgreSQL primary and no production regional replicas. Its maxStalenessMs bounds the age of its canonical primary database snapshot, not delivery time from an external issuer. A strict-plan check currently reads the primary; it does not synchronize all external authorities. There is no enterprise SLA or independent security certification yet.

Help test whether this should exist

The central question is still open: do developers with real agent delegation problems find a separate, protocol-neutral authority-state network valuable? We are looking for independent teams willing to integrate their own authority source, measure revocation delivery and tell us candidly whether they would keep using it.

Run the demo, connect a signer, or apply for the first external developer cohort. Please keep critical production workloads on independently audited security controls.