You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GitHub resource creation (PRs, issues, comments, commits/pushes) should go back to acting as Junior (app/installation/service-principal identity), not as the requesting user via their OAuth token. More broadly, this is the default intent everywhere: Junior acts as itself where possible; delegated user credentials are the exception, reserved for operations that inherently require the user's identity (user-private resource access, user-consented reads).
Humans get credited through attribution metadata, not borrowed identity: Co-Authored-By trailers for all run actors (#777), "requested by" references in bodies/descriptions, and creator audit fields — the same split the scheduler already uses (system actor executes, createdBy is audit metadata; see specs/identity.md).
Rationale
This is the agent-as-teammate answer to the confused deputy problem (#773). Acting as the user makes every multi-actor run a delegation problem: which user's token, what happens when another actor steers, what the audit trail means. Acting as Junior makes execution authority uniform and auditable regardless of how many actors are in the run, and turns human attribution into explicit, verifiable metadata. It also shrinks the surface that point-of-action authority checks (#773 section D) must guard — operations under Junior's own identity have no cross-actor credential conflict by construction.
Scope
Inventory which GitHub operations currently execute with user-delegated tokens vs app/installation identity; revert creates to Junior's identity.
State the general default in specs/identity.md (and cross-reference from specs/credential-injection.md): service-principal/system identity is the preferred execution identity; delegated user credential subjects only where the operation requires user identity, per existing spec exceptions.
Repo permissions: Junior's app/installation identity needs write access wherever users previously supplied it via their own tokens.
Notification semantics change (created-by-Junior does not @-notify as the user would); decide whether bodies should mention the requesting actor for visibility.
Any GitHub surfaces that genuinely require user identity (e.g. reviews that must come from a human) — enumerate and keep those on delegated credentials explicitly.
Policy
GitHub resource creation (PRs, issues, comments, commits/pushes) should go back to acting as Junior (app/installation/service-principal identity), not as the requesting user via their OAuth token. More broadly, this is the default intent everywhere: Junior acts as itself where possible; delegated user credentials are the exception, reserved for operations that inherently require the user's identity (user-private resource access, user-consented reads).
Humans get credited through attribution metadata, not borrowed identity:
Co-Authored-Bytrailers for all run actors (#777), "requested by" references in bodies/descriptions, and creator audit fields — the same split the scheduler already uses (system actor executes,createdByis audit metadata; seespecs/identity.md).Rationale
This is the agent-as-teammate answer to the confused deputy problem (#773). Acting as the user makes every multi-actor run a delegation problem: which user's token, what happens when another actor steers, what the audit trail means. Acting as Junior makes execution authority uniform and auditable regardless of how many actors are in the run, and turns human attribution into explicit, verifiable metadata. It also shrinks the surface that point-of-action authority checks (#773 section D) must guard — operations under Junior's own identity have no cross-actor credential conflict by construction.
Scope
specs/identity.md(and cross-reference fromspecs/credential-injection.md): service-principal/system identity is the preferred execution identity; delegated user credential subjects only where the operation requires user identity, per existing spec exceptions.Open questions
Related
Part of the #773 follow-up set.