Complete GH-WP-0001-T04 authority context contract

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a05e30-2884-71b0-98d7-7edd16ae737b

docs/adr/ADR-002-principal-actor-runtime-identity-model.md

@@ -0,0 +1,82 @@
+# ADR-002 — Principal, actor, and runtime identity model
+
+**Repository:** gate-house  
+**Status:** accepted  
+**Date:** 2026-09-01  
+**Workplan:** GH-WP-0001-T04
+
+## Context
+
+Agentic execution introduces at least three identity questions:
+
+- on whose behalf does authority originate;
+- who is directly attempting the action;
+- which concrete workload instance will execute it.
+
+A single `subject`, `user`, or service-account field cannot answer all three.
+Collapsing them permits invisible impersonation, obscures delegation, makes a
+reusable service identity look like a concrete runtime, and prevents evidence
+from showing whether a human, agent, or workload actually acted.
+
+The roles can sometimes resolve to the same underlying subject in a direct,
+non-delegated operation. That does not make the roles synonymous.
+
+## Decision
+
+Principal, actor, and runtime identity are separate semantic roles throughout
+authority input and decision evidence:
+
+- **Principal** is the human, organization, workload, or system on whose behalf
+  authority originates.
+- **Actor** is the entity directly attempting the action and authenticating as
+  itself.
+- **Runtime identity** is the concrete workload instance performing execution.
+
+Implementations must preserve the three roles independently and bind each to
+the appropriate authoritative evidence. They must not fill one missing role by
+copying another, use impersonation to hide the actor, or replace a concrete
+runtime identity with a reusable actor/service name.
+
+In Assistant mode, the active supervising human is principal and the agent is
+actor. In Autonomous mode, the autonomous actor has an independent identity,
+and its principal relationship is established through the organizational
+context and governed mandate. Both modes identify the concrete runtime.
+
+Delegation preserves the originating principal and authenticates the actor as
+itself. Delegated and child authority attenuate; identity linkage never widens
+the authority ceiling.
+
+The roles need not all be embedded in one token. They must remain verifiably
+linked across identity, authorization, credential issuance, execution, and
+decision evidence.
+
+## Consequences
+
+- Policies can distinguish who benefits, who requests, and which workload
+  executes.
+- Assistant actions remain attributable to both the supervising human and the
+  assisting agent.
+- Autonomous actors cannot rely on a borrowed human identity or a shared
+  generic machine identity to erase accountability.
+- Runtime replacement or replay can be evaluated separately from actor
+  identity.
+- Existing transports with one subject field need an explicit mapping or an
+  extension before they can conform to `authority-context.v1`.
+
+## Alternatives rejected
+
+### One canonical subject
+
+Rejected because it erases delegation and cannot represent the agentic chain
+without overloading one identifier.
+
+### Principal and actor only
+
+Rejected because a stable actor identity does not identify the concrete
+workload instance that executed a particular action.
+
+### Treat runtime identity as audit-only metadata
+
+Rejected because runtime identity can be security-relevant policy input and
+must be bound before a positive decision when policy depends on it.
+Reconstructing it after execution is too late to enforce the boundary.