Skip to main content

Authority gateway for AI agents

GitHub design-partner pilot Live acceptance not run

Give agents bounded authority without giving them the credential.

RANKIGI evaluates the scope a customer authorized, refuses requests before provider contact when authority is absent, and records the provider outcome for independent offline review.

Agent receives
One typed tool and its bounded request contract
Gateway holds
Customer-side enforcement and credential resolution
Reviewer receives
Granular claims and an offline evidence packet

Scenario model, not a live acceptance artifact

One request. Two authority outcomes.

Live acceptance not run
A

Outside approved repository

Same typed action, repository outside the effective scope.

denied
Toolwork.issue.create
Decisionrepository_outside_effective_scope
Provider contactNo contact
Outcome claimdenied
Offline packet checksGranular denial checks
B

Inside approved repository

Exact repository, action, workload, run, and content constraints.

effect_confirmed
Toolwork.issue.create
AuthorityDurable reservation
Provider contactAt most one create POST
ObservationIndependent retrieval
Offline packet checksSame-operation evidence

Authority chain schema example

Inspect the commitment, not a green badge.

No operation was run. Values below are illustrative and support only the displayed checks.

Each displayed predecessor value matches the prior displayed event hash.No displayed mismatch result is present. Some checks remain not_run.

External anchor receipts

Separate trust domains attach to the packet commitment only when their exact artifacts are present and checked.

  • Rekor inclusionanchor_inclusion_supportednot_run
  • RFC 3161 timestamptimestamp_token_supportednot_run

Offline verification

Inspect every supported check, including the limits.

The packet is designed to travel outside the dashboard. The verifier reports individual checks and leaves unsupported facts unclaimed.

Review the verification boundary

Verify the packet offline

The verifier recomputes canonical hashes, receipt signatures, and Merkle inclusion checks without calling a RANKIGI service.

Implemented check: Reports only the checks the verifier actually performs.

Limit: Does not establish that the action was wise, complete, or aligned with human intent.

No aggregate verified state

Evidence is reported as specific lifecycle states and individual checks. Unknown evidence stays unknown.

Implemented check: Makes each supported claim and each failed, uncertain, or unrun check visible.

Limit: Does not turn a signature, observation, or provider submission into a broader fact.

Open verification inputs

The Authority Grant schema, receipt format, canonicalization rules, test vectors, and verifier are designed to remain independently checkable.

Implemented check: Lets a reviewer inspect the verification rules and reproduce supported checks.

Limit: Does not require trusting a dashboard label or a proprietary aggregate verdict.

Product status

Implementation is testable; live GitHub acceptance has not run.

Implemented and tested

  • Signed governed-artifact and evidence contracts have cross-language protocol vectors.
  • The dedicated customer runtime loads protected configuration and current execution material; its readiness check requires the exact governed_github_pilot PostgreSQL profile before /readyz returns 204.
  • The GitHub connector binds one installation and numeric repository, permits at most one create POST per operation, and retrieves the bound issue independently.
  • The offline v0.3 verifier reports granular supported, unsupported, failed, and unrun checks without an aggregate verdict.
Review pilot acceptance

Acceptance remaining

  • Run one deployed profile for one organization, one customer-owned GitHub App, one repository, and work.issue.create.
  • Prove an out-of-scope denial before AWS or GitHub contact and verify its denial packet offline.
  • Create exactly one GitHub issue, retrieve it independently, and verify the same-operation Authority Packet offline.
  • Inject an ambiguous response after possible provider acceptance and prove that recovery never sends a replacement POST.
Discuss a scoped pilot