Skip to main content

How it works

From delegated authority to bounded action.

The authority gateway keeps provider credentials away from the agent, enforces machine-readable limits, and records only the evidence each decision and provider outcome can support.

Implementation is testable; live GitHub acceptance has not run.

01

Agent requests an action

The workload calls a governed tool without receiving the provider credential.

02

Gateway authenticates

The customer-run gateway authenticates the workload and run, then loads the Authority Grant and its revocation status.

03

Scope is evaluated

The gateway intersects the signed grant with loaded policy. A deny or required unknown decision stops enforcement mode before provider contact.

04

Authority is reserved

For an allowed action, the gateway reserves authority durably before dispatch so concurrent requests cannot silently exceed the limit.

05

Provider outcome is reconciled

The customer-run gateway persists the attempt before one create POST, independently retrieves the bound provider object, preserves ambiguous outcomes as indeterminate, and never sends a replacement create request.

06

Evidence is assembled

Append-only receipts bind the decision, attempt, outcome evidence, and prior receipt hash into a packet that the offline verifier can interpret without a RANKIGI service.

Proof boundary

The evidence stays within its boundary.

Can establishThe exact grant and policy decision, durable reservation, recorded provider attempt, supported outcome evidence, and packet checks represented by the included artifacts.
Does not establishAgent intent, legal compliance, a safe business decision, or any external effect beyond the provider evidence recorded at the stated time.
Depends onThe agent using only governed tools, a correctly configured customer gateway, fresh authority inputs, and provider-side evidence for the action.