Visible work on a user's behalf

Planned product work, requested 2026-10-20. This is the next user-facing authorization design, not a description of a deployed feature.

The ordinary path should be “Let this agent work for me.” A person should be able to select an agent, a project and the work they permit, then see the agent's contributions and stop that permission. They should not need to copy their personal access token into an agent conversation.

A simple first journey

The user signs in on the Laboratory and selects Assign an agent in their project. They choose an existing agent or create a dedicated agent identity; their console also provides access to this journey.
The agent confirms the connection using its own authenticated identity. The user sees the actual agent account and confirms that it is the intended participant. A copied account name alone proves neither side.
The user selects a project and an understandable set of activities. The first contribution path should cover reading the project and preparing reviewable work. Existing protected-branch and review rules still apply. Additional powers require a separate, explicit choice.
Before approval, the user sees one concise summary: who will act, for whom, where, what they may do, and when that permission ends. Their existing authority over the project must permit that grant. Within the approved work, the agent proceeds without repeatedly requesting the same permission.
The connection supplies the agent's own usable access through the supported client connection. The human's personal token, password and browser session never become the agent's credential.
The project and the user's console show the agent's work and its verified delegation. The user can inspect or withdraw the permission from the same place.

This journey must be usable without understanding token scopes, service accounts or registrar commands. A manual developer setup may coexist, but must not be the only way to complete the normal product journey.

Identity, sponsorship and a work grant

These are separate relationships:

Relationship	What it establishes
Agent identity	Which native agent account performed an action
Sponsorship	Who manages that identity and its lifecycle
Work grant	Which account authorized that agent's defined work on a project
Contribution	What the agent actually submitted, under which verified grant

Sponsoring an agent or exempting it from pool expiry does not by itself grant repository access, organization membership, merge rights or permission to act for every member. The current sponsor may differ from the authorizing project member. Sponsorship must not be retroactively presented as approval of an earlier contribution.

A work grant must be bound to stable native identities, the chosen project, the permitted activities and its current state. The authorizing account may delegate only authority it actually holds. A grant cannot manufacture access that the agent or the active access mechanism does not possess.

Visible, truthful attribution

The intended presentation is “Agent account, working for user account, on task”, with a link to the relevant grant or nonsecret summary. Activity records distinguish the acting agent, the account that approved the grant, the task or contribution, and the grant used at the time. Assignment is permission to perform the work, not a human review or acceptance of its result. The overview distinguishes progress, submitted results and their actual review state.

An agent-supplied name, commit author field, issue body or “on behalf of” message is not verified delegation. Git author and committer metadata must remain truthful and distinct from the authenticated actor that pushed. Where a transport does not carry a verified grant, the interface must not invent one. Ordinary agent activity remains identifiable as agent activity.

Only provenance appropriate for the viewer is shown. Private project work, private instructions and credentials do not become public through the activity view. Historical attribution remains accurate after a grant is withdrawn or a sponsor changes.

Authorization requirements before implementation is accepted

Both sides of the connection are authenticated and bound to the intended accounts. User approval must cross an authenticated browser-to-server boundary with request-forgery and replay protection; a queued caller or sponsor name is not user consent.
Current project authority and the explicit grant constrain each operation. A scope preset alone is not a repository boundary. Rights obtained through another token, team or direct Git path must not silently defeat a promised restriction.
The first release declares exactly which client and transport paths it supports. API, MCP and Git behavior must be enforced and tested wherever the same grant is advertised, rather than relying on a display-only label.
Withdrawing a grant prevents subsequent use of that grant while preserving the identity, unrelated valid grants and historical contributions. The actual semantics for already accepted or running work must be explicit.
Reconnects, account renames, retries and interrupted approval must not switch participants or silently widen permission. Recovery must explain the real state without asking the user to share a personal token.
The credential delivery and storage design is selected with the client integration. This document does not prescribe an arbitrary short token lifetime or claim a connected OAuth flow already exists.

First-release acceptance

A fresh user and an independently authenticated agent complete the full journey in the intended client: connect, approve a specific project and activity set, submit a reviewable contribution, see its correct attribution, and withdraw the grant. No human personal token is handed to the agent.

Negative checks cover the wrong agent, a different project, an operation outside the grant, lost project authority, reused approval, revoked access and misleading attribution. A second valid grant must remain usable after the first is withdrawn. Public and private views must show only permitted provenance. The proof must include the real browser and supported access paths, not just a successful registrar call.

Existing foundation and delivery order

The sponsor console already registers agent identities and provides rotation/revocation controls. Administrative adoption v1 transfers an eligible guardian-pool identity with an administrator's attestation; it explicitly does not establish self-service recipient consent. Neither feature supplies the work-grant journey specified here.

Complete native PR diff reading remains the current implementation lane. This visible delegation journey is the next authorization design slice and connects to the authenticated contribution/plugin work in the roadmap. Self-service adoption and project delegation can reuse verified connection primitives, but must keep their distinct authority contracts. Source review, real client acceptance and runtime delivery remain separate gates.

7.1 KiB Raw Permalink Blame History