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

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.