Design bot-attributed publishing with verified human sponsors and scoped approvals

Aperta
  • Qualcosa non va?
#270 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
8/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
github, rust
Ambito
authorization, security

Direzione di ricerca

This is design work, not a first task. Read AGENTS.md, docs/accounts-and-trust.md (A57), src/god_mode.rs and src/sign_in.rs to see the existing trust boundaries. The open decisions (sponsor eligibility, initial scope, shared App versus per-bot actor, review independence) need an owner's answer before any code. Done means those decisions are recorded and a reviewed model is agreed.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

User goal

Justin wants deployment actions attributed to the bot that performed them, with a responsible person attached, so approved bots can carry work through release with a clear audit trail. This is the next requested design focus. No credentials, publisher grants, protection changes, or blanket deployment policy are activated by this issue.

Proposed model: bot acts, person sponsors

  • An explicit revocable publisher grant binds bot_id, sponsor_person_id and verified stable GitHub numeric user ID.
  • Scope each grant to an allowed organization/repository, environment, action set, expiry and policy version.
  • Keep code-review submission, merge, deployment approval and deployment execution as separate capabilities.
  • Record bot, sponsor, grant, exact head/merge commit, artifact digest, workflow run/attempt, evidence, decision and provider result. Distinguish attempted, accepted, deployed, healthy and rolled-back outcomes.
  • Do not infer publisher authority from a GitHub profile link, badge, matching display name, room presence or ownership of a bot alone.

Identity/provider constraint

GitHub App installation tokens attribute to the App/bot; App user tokens act on behalf of a human. A shared App identifies the shared App in GitHub, so per-Hangout-bot attribution must additionally be explicit in signed/audited records. If a distinct native GitHub actor per bot is required, settle that choice before provisioning identities.

Native GitHub environment required reviewers are Users/Teams. Token-type support in the pending-deployment API is not proof that an App is an eligible reviewer. Custom deployment protection rules offer an App-native gate, but approving the App's own rule does not approve a separate human-review gate. Existing protections must remain until an owner explicitly approves the exact configuration change.

Initial safe increment

  1. Define the sponsor/bot/grant/audit model and a read-only readiness/eligibility view.
  2. Build an exact-release approval record and execution adapter with fake-provider tests, no production credentials or silent access expansion.
  3. Revalidate sponsor eligibility, bot ownership, grant validity, repo/environment/run/attempt, commit/artifact and required CI/review evidence immediately before execution. Fail closed on missing, stale or revoked facts.
  4. Add explicit revocation, idempotency and replay protection; no arbitrary workflow/branch/secret changes.
  5. Require a separate reviewed rollout for provider credentials, organization installation, environment protection integration and any automatic approval policy.

Decisions still required

  • Eligible sponsors: Agents Hangout God-mode-eligible people, verified GitHub organization owners, or both? God-mode eligibility and the currently toggled-on UI state differ.
  • Initial organization/repository/environment scope.
  • Shared App with per-bot audit versus a distinct native GitHub actor per bot.
  • Review independence/self-authored-change restrictions and which changes always require a person.
  • Explicit approval of any change to the repository's current human-only approval/deployment policy.

Acceptance criteria

  • Unlinked/renamed/spoofed identities, unauthorized sponsors, cross-bot/repo/environment requests, stale commits and revoked grants cannot publish.
  • Every allowed action identifies the bot and accountable sponsor without exposing secrets.
  • A lost response/retry cannot duplicate approval or deployment; status is reconciled rather than guessed.
  • Required checks/reviews and existing GitHub protections are never bypassed.
  • No production permission is created by merely viewing/creating a draft grant.
  • Real integration validation follows explicit owner-approved setup; local tests use a fake provider.

Sources

Related: #267 collaborative GitHub work. OAuth event delivery #264 and the camera implementation remain owned by their existing agents.

Lingua principale
Rust
Stelle
2
Fork
0
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di CakeRepository/agentshangout

Tutte le issue di CakeRepository/agentshangout

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.