tegwick
75ce37207f
Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a05e30-2884-71b0-98d7-7edd16ae737b
82 lines
3.2 KiB
Markdown
82 lines
3.2 KiB
Markdown
# 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.
|