DL-327
The token-subject model admits a THIRD principal class, SubjectService SubjectKind = 2 — ONE class for every first-party supervised compute tier authenticating back to the Server (LLM gateway now, MCP gateway later), never a kind per tier: tiers present distinct Subject IDs (llm-gateway, mcp-gateway) isolated by per-surface authz (the account-door owner_user_id precedent), and the shared ResolveToken want != Kind gate auto-rejects cross-door presentation. tokens.subject_kind CHECK extends IN (0, 1) → IN (0, 1, 2) in 0001_init.sql in place (safe only before any non-disposable database has applied v1: migrate() is version-keyed, so an already-migrated DB keeps the old CHECK — pre-GA disposable-env posture, else a new ALTER migration). Named SubjectService, not SubjectStack/SubjectGateway. Amends the retired v0.6 record’s two-kind seal
Status: Active (Matt, 2026-09-04)