Skip to content

[URGENT] Approval: senior dev agent onboarding and GitHub identity model #9

Description

@0xMadie

[URGENT] Approval request: senior dev agent onboarding and GitHub identity model

Requested approvers: @helloscoopa, @rasmr
Looped in: @cmnisal

Request

Please review and approve the proposed onboarding path for senior development agents:

  • BackendBanda — senior backend / CI/CD / DevOps agent.
  • UiUxAkka — senior UI/UX / frontend / product experience agent.

These agents should be introduced to CeyLabs as senior dev agents, but with constrained GitHub permissions and explicit review gates.

Proposed access model

Default access should be least-privilege:

  • triage for repo visibility, issue/PR triage, and status coordination where possible.
  • No direct push to main.
  • No merge rights by default.
  • No access to secrets unless explicitly approved for a narrow task.
  • All implementation work must go through branches and PRs.
  • PRs require local checks, GitHub Actions verification, PR testing checklist evidence, CodeRabbit review, and human approval before merge.

GitHub App vs new GitHub user

Question for @helloscoopa in particular: should these agents be represented as GitHub Apps or as new GitHub users?

My current recommendation is GitHub Apps first.

Why GitHub Apps are safer:

  • Installation-scoped permissions can be limited per org/repo.
  • Permissions are explicit and easier to audit.
  • Tokens are short-lived and rotatable.
  • Easier to disable one agent without touching human or shared credentials.
  • Better fit for automation, checks, PR comments, issue triage, and status reporting.

Where a GitHub user may still make sense:

  • If the agent needs normal GitHub UI behavior that Apps cannot perform.
  • If CeyLabs wants a visible human-like identity for social/profile continuity.
  • If a specific workflow cannot be performed through a GitHub App permission model.

Risk with GitHub users:

  • PAT/SSH credentials are easier to over-scope.
  • Long-lived credentials increase operational risk.
  • Shared machine-user identities can blur accountability unless tightly governed.

Suggested decision:

  • Use GitHub Apps for operational access by default.
  • Create separate GitHub users only if a workflow proves GitHub Apps cannot support it.
  • If a user account is needed, keep it triage/read-focused by default, enforce 2FA, avoid broad PATs, and document who owns recovery and credential rotation.

Approval format

Please reply with one of:

  • Approved: GitHub Apps
  • Approved: GitHub users
  • Approved with changes: ...
  • Not approved
  • Needs discussion: ...

After approvals from @helloscoopa and @rasmr, @0xMadie can proceed with the approved identity model and keep @cmnisal looped in before any creation or binding work.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions