Status of this document

H33-API-G is a governed access pilot. It is not a production-admitted authority, and nothing in this paper should be read as a claim that it is. This document defines a category and an architecture; it does not report production results, and where a number would normally appear, none does. The product page carries the same limitation, and the whitepaper index records this artifact as a draft under review.

Abstract

API security has spent fifteen years perfecting admission. Gateways terminate TLS, validate tokens, enforce quotas, and route traffic. Identity providers issue credentials and rotate them. Key managers protect the material those credentials are built from. Each of these layers is mature, and each answers a question about reaching an endpoint.

None of them answers whether the action carried by the request was authorized. A valid OAuth token proves that a credential was issued and has not expired. It does not encode which decision permitted POST /production/deploy at 03:14 on a Sunday, who made that decision, what it was scoped to, or whether it still holds. In practice, the authorization is reconstructed after the fact from logs — records written by the system that acted, describing what it decided to do.

This paper defines Governed API Authority: a layer that evaluates a specific request against a recorded authority state before execution, refuses execution when that authority is absent, and emits an evidence receipt for both outcomes. It is not an API gateway, an authentication system, a key manager, or a firewall — those are adjacent categories that answer adjacent questions, and §7 states the boundaries precisely.

Who should read this

• Platform and infrastructure architects deciding where authorization belongs when service-to-service calls cross trust boundaries.
• Security engineers who have concluded that their audit trail describes activity rather than proving authority.
• Teams deploying autonomous agents, where the caller is a program that holds a credential and composes its own requests.
• Auditors and insurers who need to answer "was this action authorized?" months later, from evidence that does not depend on trusting the actor's own logs.

1 · Why authenticated API calls are insufficient

Consider a request that every control in a modern stack accepts:

POST /production/deploy
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
X-Request-Id: 8f21c4a0

  TLS               valid
  Token signature   valid
  Token expiry      valid, 41 minutes remaining
  Scope             deploy:production  ✓ present
  Rate limit        within quota
  mTLS peer         verified
  Source            inside the service mesh

  Result            202 Accepted

Every check passed. Now ask a different question — not could this request reach the endpoint, but was this deployment authorized:

• Which decision permitted it? The token proves a credential was issued to a principal weeks ago. It says nothing about the specific deployment.
• Under whose authority? The scope deploy:production was granted to a role. A role is a container for permissions, not a record of a person deciding that this change may ship.
• Was the authority still valid? Credentials expire on a clock. Authority expires on events — an approval withdrawn, a change window closed, an incident declared. The token knows nothing about any of them.
• What evidence survives? An access log line, written by the service that executed the action, saying it executed the action.

The gap is structural rather than a matter of configuration. Authentication establishes a fact about the caller that persists for the lifetime of the credential. Authorization of an action is a fact about this request at this moment. Systems that derive the second from the first are performing an inference, and the inference is not recorded anywhere, which is why it cannot be examined afterwards.

The most expensive breaches of the last decade did not defeat authentication. They used it. A valid credential in the wrong hands produces a stream of perfectly authenticated requests, and every one of them is indistinguishable, at the admission layer, from work the organization intended.

2 · The separation

The confusion this paper addresses comes from collapsing five distinct questions into one credential check. They are separable, they fail independently, and a system that conflates them cannot report which one failed.

Layer	Question it answers	Where it is usually decided	What survives the request
Identity	Who or what is this?	IdP, workload identity, mTLS peer	A subject name
Authentication	Is that claim genuine right now?	Token validation, certificate verification	A verified session
Authorization	Is this subject permitted this class of operation?	RBAC/ABAC policy, scopes	A permit/deny at the boundary
Authority	Was this specific action permitted, by whom, under what constraint, and does it still hold?	Nowhere — inferred from the layers above	Nothing
Evidence	Can that be shown later, independent of the actor?	A log the actor wrote	A claim, not a proof

The first three rows are well served by existing infrastructure and this paper proposes no replacement for any of them. The last two rows are the subject.

Authority is not a stronger permission. A permission is a standing statement about a subject: this role may deploy to production. Authority is a bounded statement about an action: this deployment, of this artifact, within this window, permitted by this decision, which has not been withdrawn. The two have different lifetimes, different subjects, and different failure modes, and a system that stores only the first cannot answer questions about the second.

3 · Why bearer tokens fail as authority

A bearer token is, by construction, a secret whose possession is the entire proof. That property is what makes it convenient and what makes it unusable as authority.

3.1 · A bearer token is copyable

Anything that can read the token can present it, and the presentation is indistinguishable from the original holder's. The token carries no binding to the request it is being used for, so a token captured from a log, a proxy, a browser extension, an environment variable, or a CI job produces requests that verify exactly as the legitimate ones do.

3.2 · A bearer token is unscoped to the action

Scopes name classes of operations, not operations. deploy:production permits every production deployment for the life of the credential. The gap between "may deploy" and "may deploy this" is where the interesting failures live, and it is invisible to the check.

3.3 · A bearer token expires on the wrong axis

Tokens expire on a clock. Authority is revoked by events: an approval rescinded, a maintainer offboarded, a change freeze declared, an incident opened. Between the revoking event and the token's expiry, the credential remains valid and every control continues to accept it. Shortening token lifetime narrows this window; it does not change the axis.

3.4 · A bearer token records no decision

This is the deepest problem, and it is not fixable by making tokens shorter-lived, sender-constrained, or post-quantum. Even a perfect credential — unforgeable, bound to its holder, valid for one second — proves that a credential was issued. It does not carry the decision that authorized the action, because no such decision was captured at issuance. The credential was issued to a principal; the action had not happened yet.

Sender-constrained tokens (mTLS-bound, DPoP) close the theft gap and leave the authority gap untouched. They prove the presenter is the holder. They still do not prove that anyone authorized the action the holder is requesting.

4 · Why custody is not authorization

Key management, HSMs, and secret stores answer a custody question: where the key material lives, who may retrieve it, how it is rotated, and whether it ever appeared in plaintext outside a boundary. These are real guarantees and H33-API-G depends on them.

Custody is a statement about a secret. Authorization is a statement about an action. A key that never leaves an HSM can still sign an operation nobody approved, because the HSM was asked to sign and the request satisfied its access policy. Perfect custody with no authority layer produces perfectly protected keys performing unauthorized work.

The same distinction is what H33-Key exists to make on the secret side — knowing where a key exists is not the same as knowing whether it may be used. H33-API-G makes it on the action side. They are the same principle applied at two layers, which is why they compose (§8).

5 · Monotonic authority across hops

A modern request is rarely one call. A user action becomes a service call, which becomes three internal calls, one of which reaches a third party. Authority must survive that path without growing.

Client ──▶ Service A ──▶ Service B ──▶ Service C ──▶ external

  Authenticated at every hop:          yes
  Authority carried across hops:       ?
  Authority ATTENUATED at each hop:    ?

  Common outcome: Service A holds a narrow user authority and
  calls B with its own broad service credential. The user's
  constraint is dropped at the first hop and never recovered.

H33-API-G treats authority as monotonically non-increasing along a call chain. A downstream call may carry the same authority or a narrower one. It may never carry more. The property is stated deliberately in the negative, because the failure it prevents is privilege re-acquisition: a service holding broad standing credentials being used, knowingly or not, to perform work that the originating authority did not permit.

Two consequences follow. Delegation must be explicit rather than ambient — a downstream call presents an attenuated authority derived from the upstream one, not the caller's own standing credential. And a refusal at hop three must be attributable to the constraint set at hop zero, which requires the constraint to have travelled, not been re-derived.

6 · Evidence receipts

Every governed call produces a receipt. Both outcomes produce one: a refusal without a receipt is indistinguishable from an outage, and an execution without a receipt is a claim the actor makes about itself.

A receipt records, at minimum:

• The action — the specific operation requested, bound by a commitment to the request rather than a description of it.
• The authority relied upon — which recorded decision permitted it, its scope, and its boundary.
• The outcome — executed or refused, and for a refusal, which condition was unmet.
• The time axis — when the action occurred and when the authority state was read. These are separate, and conflating them is how a reconstruction becomes wrong later.

The distinction from logging is not format but dependency. An access log is a statement by the system that acted, and evaluating it requires trusting that system's integrity at the time it wrote. A receipt is verifiable against evidence the actor did not produce and cannot revise afterwards. That is what makes it usable in the two situations where it matters most — an audit long after the fact, and an incident in which the actor's integrity is precisely what is in question.

A refusal receipt is the more valuable artifact. It records a moment where the system was asked to act, could have acted, and did not — and states which condition was missing. No log contains this, because nothing happened.

7 · What H33-API-G is not

Category confusion is the fastest way to make this product sound like a worse version of something mature. The four adjacent categories:

Adjacent category	Question it answers	Relationship
API gateway	May this caller reach this endpoint, at this rate, over this route?	Complementary. The gateway admits traffic; H33-API-G decides whether the admitted action may execute. Sitting behind a gateway is the expected deployment.
Authentication / IdP	Is this identity claim genuine?	Depended upon, not replaced. H33-API-G consumes an authenticated identity; it does not issue, store, or verify credentials.
KMS / HSM	Where does key material live and who may use it?	Depended upon, not replaced. Custody stays where it is; H33-API-G never holds key material.
WAF / firewall	Is this traffic malicious or malformed?	Orthogonal. A firewall judges the shape of the traffic. H33-API-G judges the authority behind a well-formed, benign-looking, fully authenticated request.

The clarifying test: each adjacent category, working perfectly, still admits the request in §1. That request is well-formed, authenticated, in-scope, in-quota, and routed correctly. Nothing in the list is failing. The action is simply not authorized, and no layer above is positioned to know that.

8 · Composition

H33-API-G is one layer of a lifecycle rather than a standalone product, and it is deliberately small. What it composes with, and what each side owns:

Component	Owns	Boundary
H33-Key	Whether a credential may be used, not merely where it exists	The secret-side counterpart of the same principle. H33-Key governs use of key material; H33-API-G governs execution of actions.
KMS / HSM	Custody, rotation, plaintext boundary	Unchanged. H33-API-G holds no key material and issues no credentials.
Enterprise IAM	Identity, authentication, role and scope policy	Unchanged and authoritative. H33-API-G consumes the authenticated identity and adds the action-level authority decision the IdP was never asked to make.
Agent-008	Governed execution and decision integrity for autonomous agents	The demanding caller. An agent composes its own requests, so the gap between "holds a valid credential" and "is authorized to do this" is widest exactly where agents operate.

The agent case deserves the emphasis. Human callers are constrained by interfaces that were designed around what they are supposed to do. An autonomous agent holding a valid credential composes requests directly, at machine rate, and every one of them authenticates correctly. The authority question is not more important for agents than for people; it is simply the only question left.

9 · Limitations

Stated plainly, because a category-defining paper that omits its boundaries is marketing:

• H33-API-G does not decide policy. It enforces an authority path and refuses to execute outside it. Which actions require which authority is an organizational decision, and the product is not improved by pretending otherwise.
• It does not replace authentication, custody, or admission control. A deployment without those layers is not made safe by adding this one.
• It cannot recover authority that was never recorded. If no decision was captured, the honest answer to "was this authorized?" is that it cannot be determined — and the system says so rather than inferring an answer.
• This paper reports no production measurements. H33-API-G is a governed access pilot. Latency, throughput and failure characteristics under production load are not claimed here because they have not been established here.
• The evidence receipt format is not yet a published specification. Interoperability claims are premature and are not made.

10 · Conclusion

The infrastructure that protects APIs today is good at the question it was built for. Gateways, identity providers, and key managers each answer a real question well, and together they have made unauthenticated access rare. What they have not done — because it was never their question — is establish whether the action inside an authenticated request was authorized by anyone.

That gap is filled today by inference and by logs the actor wrote about itself. Both work until the moment they are needed most: an audit long after the event, or an incident in which the actor's own integrity is the thing in doubt.

A successful API request proves transport and authentication. It does not prove that the requested action was authorized.

Governed API Authority is the layer that answers the remaining question, refuses when it cannot, and leaves evidence either way.

Related

• H33-API-G — product page and current status
• H33-Key — the same principle applied to secret use
• Agent-008 — governed execution for autonomous agents
• H33 white papers — the full index