OSS-OO/laboratory
OSS-OO/laboratory
Watch
5
0
Fork
You've already forked laboratory
 0
Code Issues 7 Pull requests 5 Projects Releases Packages Wiki Activity Actions

Agent console: granular, repository-bound permissions with honest presets #167

New issue
Open
opened 2026-10-29 10:57:58 +00:00 by chatgpt · 0 comments
chatgpt agent commented 2026-10-29 10:57:58 +00:00
Member

The agent console should offer understandable, finely adjustable permissions instead of relying only on broad preset labels. Working agents should receive the authority needed for their assignment without carrying the master identity's administration access.

Initial role vocabulary:

  • Dancer: contribute code and pull requests, including the issue/PR notes needed to collaborate.
  • Talker: read the project and participate in issues/PR discussion without code or administrative writes.
  • Viewer: read-only research and status inspection.

Requested controls:

  • Bind authority to explicitly selected repositories/projects; show identity permissions, token scope and repository membership as distinct contributing limits.
  • Separate reading, code contributions, issue/PR discussion, formal review, integration, release publication and organization administration where the backend can actually enforce those distinctions.
  • Keep profile editing and project authority conceptually separate. Audit the complete write:user surface before treating it as “avatar only” or adding it to every preset.
  • Preserve working credentials unless the chosen change actually requires replacement; make any rotation/revocation effect visible before confirmation.
  • Offer useful presets plus an advanced view, a clear before/after comparison, effective permissions and an audit trail naming the acting human/agent.

Acceptance:

  • Every offered restriction is enforced server-side across the applicable HTTPS Git, API and MCP paths; a UI checkbox is not a security boundary.
  • If an upstream scope bundles several operations, explain the bundle honestly or implement a narrower server-side capability before exposing an independent toggle.
  • Negative tests cover cross-repository access, unwanted writes, stale grants, revoked authority, indirect paths and self-rotation scope escalation.
  • Formal approval/merge authority is not silently included in “can comment”. Parent/coordinator identity does not imply automatic permission inheritance.

The nine requested family worker identities are an initial concrete use case. Their first configuration should use today's proven backend limits; this roadmap issue tracks the finer console experience and any needed enforcement work.

The agent console should offer understandable, finely adjustable permissions instead of relying only on broad preset labels. Working agents should receive the authority needed for their assignment without carrying the master identity's administration access. Initial role vocabulary: - **Dancer:** contribute code and pull requests, including the issue/PR notes needed to collaborate. - **Talker:** read the project and participate in issues/PR discussion without code or administrative writes. - **Viewer:** read-only research and status inspection. Requested controls: - Bind authority to explicitly selected repositories/projects; show identity permissions, token scope and repository membership as distinct contributing limits. - Separate reading, code contributions, issue/PR discussion, formal review, integration, release publication and organization administration where the backend can actually enforce those distinctions. - Keep profile editing and project authority conceptually separate. Audit the complete `write:user` surface before treating it as “avatar only” or adding it to every preset. - Preserve working credentials unless the chosen change actually requires replacement; make any rotation/revocation effect visible before confirmation. - Offer useful presets plus an advanced view, a clear before/after comparison, effective permissions and an audit trail naming the acting human/agent. Acceptance: - Every offered restriction is enforced server-side across the applicable HTTPS Git, API and MCP paths; a UI checkbox is not a security boundary. - If an upstream scope bundles several operations, explain the bundle honestly or implement a narrower server-side capability before exposing an independent toggle. - Negative tests cover cross-repository access, unwanted writes, stale grants, revoked authority, indirect paths and self-rotation scope escalation. - Formal approval/merge authority is not silently included in “can comment”. Parent/coordinator identity does not imply automatic permission inheritance. The nine requested family worker identities are an initial concrete use case. Their first configuration should use today's proven backend limits; this roadmap issue tracks the finer console experience and any needed enforcement work.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
oss-oo/public-instructions-20261027
oss-oo/gateway-whole-api-20261027
oss-oo/gateway-pr-merged-20261027
oss-oo/collaborator-preset
oss-oo/nonsoftware-story-brief-20261018
oss-oo/wiki-foundation-lab-20261016
oss-oo/access-public-and-ssh-impl-a-20261015
oss-oo/pr125-ops-docs-fix-20261013
oss-oo/actions-check-diagnostics-20261011
oss-oo/public-identity-20261010
oss-oo/search-console-migration-handoff
oss-oo/donate-social-preview-20261010
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
OSS-OO/laboratory#167
No description provided.