Design bot-attributed publishing with verified human sponsors and scoped approvals
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 8/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- github, rust
- Domain
- authorization, security
Research direction
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.
Written by the indexing model from the issue text.
Description
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
- Define the sponsor/bot/grant/audit model and a read-only readiness/eligibility view.
- Build an exact-release approval record and execution adapter with fake-provider tests, no production credentials or silent access expansion.
- 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.
- Add explicit revocation, idempotency and replay protection; no arbitrary workflow/branch/secret changes.
- 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
- https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/about-authentication-with-a-github-app
- https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments
- https://docs.github.com/en/rest/actions/workflow-runs#review-pending-deployments-for-a-workflow-run
- https://docs.github.com/en/rest/actions/workflow-runs#review-custom-deployment-protection-rules-for-a-workflow-run
- Local trust boundaries: src/god_mode.rs, src/sign_in.rs, docs/accounts-and-trust.md A57, AGENTS.md.
Related: #267 collaborative GitHub work. OAuth event delivery #264 and the camera implementation remain owned by their existing agents.
- Dominant language
- Rust
- Stars
- 2
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CakeRepository/agentshangout
-
Difficulty 4/5 3-5 days Newbie friendliness 22/100
CakeRepository/agentshangout#370 ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
CakeRepository/agentshangout#363 ·
-
Difficulty 5/5 Over a week Newbie friendliness 12/100
CakeRepository/agentshangout#351 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 15/100
CakeRepository/agentshangout#338 · 4 comments ·
-
vendor-limitation
Difficulty 4/5 3-5 days Newbie friendliness 35/100
CakeRepository/agentshangout#319 ·
All issues in CakeRepository/agentshangout
Similar issues
-
A-linter
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
oxc-project/oxc#28783 ·
Maintainers usually reply within 1 day
-
Substrait consumer doesn't recognise `shift_left` / `shift_right` from functions_arithmetic.yamlOpenbug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
apache/datafusion#27059 ·
Maintainers usually reply within 1 day
-
Bump calamine to 0.38: RUSTSEC-2026-0436 (CFB/OLE2 panic and unbounded allocation) fails cargo auditOpen
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
docling-project/docling.rs#979 ·
Maintainers usually reply within 1 day
-
llm translation
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day