gate-house/docs/contracts/authority-context.md

Authority context contract

Repository: gate-house
Consumer: access-engine (currently flex-auth)
Status: normative for GH-WP-0001-T04
Version: authority-context.v1
Date: 2026-09-01
Records: ADR-001, ADR-002

This contract defines the context an agentic authority request must be able to express. Gate House owns the vocabulary and its invariants. Access-engine owns the request representation, authoritative resolution, policy evaluation, and decision.

The contract is a logical claims contract, not a wire format, token format, API, or executable schema. Conforming transports may represent it differently, but must preserve these meanings and relationships.

Boundary

Authority context is one input to an authorization decision. It is composed with:

• verified identity claims from the estate's identity authorities;
• the requested action, resource, and normalized parameters;
• applicable policy, approval, posture, quotas, budgets, and authority ceiling;
• authoritative tenant, environment, and resource facts.

No authority-context field grants authority by its presence. In particular, a declared principal, mandate, task, or operating mode is not proof that the declaration is valid. Access-engine must bind or resolve security-relevant claims to authoritative evidence before using them in a positive decision.

Gate House does not receive this context in-path, resolve it, or render a decision.

Logical envelope

authority-context.v1 has this logical shape:

schema_version: authority-context.v1
request_id: req-01JQY6M4N6V5

authority_context:
  principal:
    id: user:alice@example
    kind: human
  actor:
    id: agent:release-assistant
    kind: agent
  runtime_identity:
    id: spiffe://netkingdom/prod/release-assistant/7f91
  tenant:
    id: tenant:acme
  environment:
    id: production
  mandate: null
  task:
    id: release:payments:7.2.1
    kind: release
  operating_mode: assistant

The surrounding authorization request carries evidence for these claims. The logical separation is intentional:

verified_identity_claims:
  principal: identity-claim-ref:human-session-779381
  actor: identity-claim-ref:agent-session-22
  runtime_identity: identity-claim-ref:workload-attestation-7f91

The identity-claim-ref:* values are illustrative references, not a prescribed format. Identity-claim schemas and issuers are owned by the identity estate, not by this contract.

Claims

Claim	Meaning	Authority source or binding requirement
principal	Human, organization, workload, or system on whose behalf authority originates.	Bound to verified identity, an authenticated delegation, or an authoritative relationship such as a mandate.
actor	Entity directly attempting the action.	Bound to the authenticated actor identity. A caller-supplied alias is insufficient.
runtime_identity	Concrete workload instance performing execution.	Bound to verified workload identity or attestation. It is not a reusable service name.
tenant	Security and organizational domain in which the action occurs.	Resolved against authoritative tenant and resource facts. Caller declaration alone is insufficient.
environment	Governed operational environment containing the target.	Resolved from authoritative resource or zone facts. Free-form caller labels are insufficient.
mandate	Versioned reference to the standing organizational authorization defining why an autonomous actor exists.	Required and authoritatively resolved in Autonomous mode. It is neither a credential nor a grant.
task	Stable reference to the bounded unit of work for which authority is requested.	Bound to the workflow or orchestration record where one exists. Human-readable text alone must not widen authority.
operating_mode	Security regime under which the request runs: assistant or autonomous.	Declared explicitly and checked against session, identity, and mandate evidence. It must not be inferred merely to make a request pass.

Identifiers are opaque, stable identifiers in the namespace of their owning system. Display names and mutable labels may accompany them, but must not replace them in policy or decision evidence.

kind values classify the identifier; they do not imply permissions. The canonical principal kinds are human, organization, workload, and system. The canonical actor kinds are human, agent, workload, and system. A transport may use a controlled extension, but access-engine must not give an unknown kind authorization significance until policy recognizes it.

Requiredness by operating mode

The contract concerns agentic authority requests. Both modes require explicit context rather than reconstructing it later from logs.

Claim	Assistant	Autonomous
principal	Required; the actively supervising human principal.	Required; the organization, workload, or system on whose behalf the mandate exists.
actor	Required; the assisting agent, distinct in role from the human principal.	Required; the autonomous actor with its own identity.
runtime_identity	Required for the concrete agent workload/session.	Required for the concrete workload instance.
tenant	Required for tenant-scoped action; otherwise an explicit estate-defined non-tenant scope is required.	Same.
environment	Required.	Required.
mandate	Optional; it must not replace live human supervision or authorize continuation after disconnect.	Required, including an immutable version or revision when mandates are mutable.
task	Required.	Required and bounded by the mandate.
operating_mode	Required; exactly assistant.	Required; exactly autonomous.

An omitted tenant is not a wildcard. A non-tenant request must carry an explicit scope defined by estate policy; access-engine decides whether that scope is recognized.

Identity-role invariants

Principal, actor, and runtime identity are separate semantic roles even when a non-delegated operation legitimately gives two roles the same underlying subject. Conforming implementations must:

1. preserve all three roles independently in policy input and decision evidence;
2. never copy the actor into a missing principal field, or the reverse;
3. never replace runtime identity with a reusable actor or service identifier;
4. represent delegation without impersonation: the principal remains visible while the actor authenticates as itself;
5. ensure delegated or child authority does not exceed the authority available to its parent;
6. treat a mismatch between a declared role and authoritative identity evidence as a denial condition.

The model does not require every credential or token to carry every role. It requires the roles to remain linked across identity, authorization, credential issuance, execution, and decision evidence so the chain can be reconstructed.

Operating-mode invariants

Assistant

• A verified, active human session supplies the principal.
• The agent remains identifiable as actor and by runtime identity.
• Ending or losing the human session must not change the mode to Autonomous.
• A mandate, if present, cannot substitute for active supervision.
• A continuation requiring privilege after supervision ends requires a new Autonomous request under a governed mandate and independent identity.

Autonomous

• The actor uses an independent identity; no borrowed human credential may stand in for it.
• The request names an explicit, current mandate and a task within it.
• The mandate resolves to a named owner, authority ceiling, environment and resource bounds, lifecycle, and termination path.
• Runtime, concurrency, credential TTL, and applicable change-dynamics bounds are separate policy inputs or mandate facts; naming the mandate does not satisfy them by itself.

A mode transition is governance-sensitive. It is not an update to an in-flight context object and must not be implemented as fallback behavior.

Resolution and failure semantics

For a protected operation, access-engine must fail closed when:

• a required claim is absent, malformed, or uses an unsupported contract version;
• an identity role cannot be bound to verified identity evidence;
• authoritative and caller-supplied values conflict;
• tenant, environment, mandate, or task resolution is security-critical and unavailable or stale beyond policy;
• an Autonomous mandate is absent, expired, revoked, ambiguous, or does not cover the task;
• Assistant supervision is absent or no longer active;
• the operating mode is unknown or inconsistent with the evidence;
• resolving delegation would widen authority or erase the principal/actor distinction.

DEFER may be used only for non-security-critical enrichment. It is not a fallback for missing evidence needed to decide a protected operation.

Unknown extension claims have no authorization effect until this contract and access-engine policy recognize them. A consumer must not silently reinterpret a known claim or treat an unknown value as a wildcard.

Decision evidence

For each decision, the evidence must retain:

• the contract version and request identifier;
• the resolved values of all eight authority-context claims;
• the authoritative source or evidence reference used for each security-relevant resolution;
• the declared and evaluated operating mode;
• mandate and task versions where applicable;
• any conflict, omission, or stale-input reason contributing to a non-grant decision;
• the access-engine policy identifier and version that interpreted the context.

This is an attribution and reconstruction obligation, not a claim that an archive proves an event was emitted. Audit completeness remains the emitting system's obligation.

Versioning

• authority-context.v1 fixes the meanings of the eight claims and the two operating-mode values.
• Additive metadata may be transported without changing the version only when it cannot affect authorization under v1.
• A semantic change, new mode, changed requiredness, or new claim intended to affect authorization requires a new contract version and Gate House review.
• Access-engine must reject unsupported major versions for protected operations; it must not guess at compatibility.

Conformance statements

An access-engine representation conforms when it can demonstrate that:

• every logical claim maps to an unambiguous input field;
• authoritative evidence is distinguishable from caller assertion;
• the requiredness and failure rules above are enforced;
• principal, actor, and runtime identity remain separate through decision evidence;
• Assistant and Autonomous requests cannot silently fall back into one another;
• no claim in this contract grants authority without deterministic policy.