Pricing
Governed API Access

H33-API-G

APIs With Authority, Not Secrets

H33-API-G is the authority gate. It issues an authorization_id — a grant that is scoped, time-bound and revocable — instead of a static key that is valid until somebody remembers to rotate it.

Composes with Authority Center, H33-Root and H33-BIND — an admitted core product in its own right · the gate in front of Agent-008.

H33-API-G governed access pilot. Not a production-admitted authority.

Why it exists
APIs today grant access with copyable bearer tokens; possession isn't proof of permission, and there's no independent record of why a call was allowed.
Primary value
Makes every API request individually authorized.
What it does
Runs an operation only when the exact request is cryptographically proven allowed, leaving a tamper-proof receipt for every call.
Why it's different
A call executes because authority is proven for that specific request, not because a reusable token was presented — and the receipt lets anyone verify the decision later.
The separation

The gate decides. The agent acts. They never merge.

An AI agent that holds its own credential is its own authority: it can decide what it is allowed to do, and nothing outside it can withdraw that. H33-API-G exists so that never happens. The authority to act lives in the gate; the work happens in the executor; and the executor cannot promote itself into the thing that authorized it. The chain runs one way — human intent → H33-Key → H33-API-G → Agent-008 execution admission → governed AI agent actions → evidence and proof package — and no link in it can reach back and re-authorize the link above.

H33-API-G — the authority gate
Holds the grant. Answers one question per call: is this request, right now, still permitted? A withdrawn grant produces a refusal, not a slower yes.
Agent-008 — the governed executor
The AI governance and evidence platform that governs the AI agents beneath it: registration, policy evaluation, decision explanation, proof generation. It works strictly inside the boundary it was handed, never becomes the authority that granted it, and cannot widen its own scope.
H33-Key — the governed link
What a recipient actually receives: time-bound authority delivered as a link, instead of a reusable secret they must guard forever.
D8 evidence — the record
Post-quantum evidence emitted across the authorization lifecycle, verifiable by a third party without asking H33 to confirm anything.
The core difference

An authorization_id is not an API key.

This is the whole product in one sentence: a static key is a secret that means “yes” to anyone holding it, while an authorization is a reference to a grant that can be examined, expired, and withdrawn. The first can only be rotated after the damage. The second stops the next call.

A static API key
# one string. valid until a human remembers to rotate it.
API_KEY = "sk_live_…"

# the server can answer exactly one question:
#   is this string known?
Possession is permissionNo record of why
An H33-API-G authorization
authorization_id

# the gate can answer the questions that matter:
#   is this grant still live?
#   has this effect already been consumed?
#   what evidence did this call leave?
RevocableSingle-use effects
The lifecycle

Request, invoke, evidence, verify, revoke, denied.

This is the sequence H33-API-G demonstrates in the pilot today. Every stage produces something an outside party can check — and the last stage is the one that distinguishes a governed authorization from a secret: after revocation, further use is refused.

01
Request authorization
The caller asks for authority for a specific operation. The gate issues an authorization_id. No reusable secret is minted.
02
Invoke
The operation runs only while its authority holds. The grant is checked at the call, not at issuance time.
03
Evidence emitted
D8 post-quantum evidence is produced for the invocation — a record of what was authorized and that it ran.
04
Verification
Third-party checking is not yet available for production receipts. Verification does not require trusting the service that produced it.
05
Revoke
Authority is withdrawn. Nothing has to be rotated, re-deployed, or hunted down across environments.
06
Further use — DENIED
The next call on that authorization is refused. This is the state a leaked API key can never reach.
Two properties worth naming

Effects are single-use, and grants survive a restart.

Replaying a captured invocation is the oldest attack against a request-signing scheme. In the pilot, a replayed invocation is refused: the effect has already been consumed, and the gate says so by name rather than silently doing the work twice.

Replay of a consumed invocation
# the same invocation, submitted a second time

DENIED
ReplayState(AlreadyConsumed)
Single-use effects
Restart durability
# the gate process restarts

# the grant is still there.
# authority is durable state, not
# something held in memory.
Durable substrate
The capability boundary

A governed capability, not a shell.

A grant is only meaningful if it names what it refuses. The pilot’s Agent-008 capability is deliberately narrow: the recipient gets authority to register AI agents, evaluate their decisions against governed policy, explain those decisions, and produce evidence — for a bounded window, and nothing else. The denial list is the product, not the fine print.

Allowed pilot capabilities
  • Register an AI agent
  • Evaluate agent decisions against governed policies
  • Investigate and explain governance decisions
  • Generate compliance proofs
  • Export auditor-ready evidence packages
  • Review agent posture and governance state
Explicitly denied
  • Production changes
  • Credential access
  • Persistence
  • Autonomous remediation
  • Arbitrary command execution
  • Unbounded agent actions
Build status — stated plainly

The Agent-008 execution seam is being built. What H33-API-G demonstrates in the pilot today is the authority lifecycle above: authorization, invocation, D8 evidence, revocation, and refusal after revocation. The gate does not yet dispatch to the Agent-008 runtime, so no page here claims that Agent-008 execution results are bound into evidence receipts today. The capability boundary is what the grant will carry when that seam lands.

Pilot status

The service reports its own standing.

You do not have to take our word for what this is. The pilot endpoint publishes its environment, its admission status, and the digest of the binary that is actually running — so a reader can tell a pilot from a production authority without asking anyone.

GET /health
{"status": "ok", "environment": "pilot"}
GET /version — fields reported
service
environment              pilot
admission_status         not-production-admitted
runtime_identity
runtime_id
artifact_digest          # SHA3-384 of the running binary
product_lane             # build commit
authority_reference
What this is, and is not

H33-API-G governed access pilot. Not a production-admitted authority. The endpoint reports admission_status: not-production-admitted about itself, and nothing on this page should be read as a certification, an admission decision, or a guarantee of any security property that has not been demonstrated. No uptime, latency, or throughput figures are published for the pilot.

See it

Walk the lifecycle end to end.

The walkthrough takes you through creating a trial identity, receiving a governed link instead of a key, authorizing Agent-008 for a narrow governance capability, evaluating an AI agent’s decision against governed policy, reading the evidence receipt, and then watching the same credential that worked all week stop working on its own. It is an illustrative client-side reproduction of the contract described on this page — it does not call the pilot endpoint.

H33-API-G governed access pilot. Not a production-admitted authority.

An introduction to H33-API-G.

Watch: H33-API-G — Authority-based API execution →

Go deeper

Proof Lab
Valid but Unauthorized
Everything passed. The action still did not execute — and the refusal names the missing condition.
White Paper · Draft
A Valid Request Is Not an Authorized Action
The category definition: identity, authentication, authorization, authority, evidence — and why the last two are decided nowhere.

Frequently asked

Answers projected from the H33-API-G authority record.

What is H33-API-G?

H33-API-G is a governed post-quantum API authorization layer that controls whether API actions are permitted based on cryptographic authority, policy, and evidence rather than transport or token possession alone.

How is this different from an API gateway?

A gateway decides whether a caller may reach an endpoint. H33-API-G decides whether a specific request is authorized to execute, and leaves a receipt showing why. A call executes because authority is proven for that exact request, not because a reusable token was presented.

Why are bearer tokens not sufficient?

APIs today grant access with copyable bearer tokens. Possession is not proof of permission, and there is no independent record of why a call was allowed.

What evidence does a call produce?

Every call leaves a tamper-proof receipt, so the authorization decision can be verified later by someone who was not present when it was made.

Is H33-API-G available in production?

No. H33-API-G is currently a governed access pilot and is not a production-admitted authority.

What does H33-API-G compose with?

H33-Key, H33-BIND and HATS. Authority Center describes H33-API-G, but does not own it — H33-API-G is an admitted core product in its own right.

One cryptographic foundation H33-API-G is one application of the shared H33 cryptographic foundation — fully homomorphic encryption, zero-knowledge proofs and post-quantum keys behind a common API. ArchitectureCommon APIThe product family