Section 1 — Ownership and Shared Access
Companion to
musehub-production-readiness-checklist.md. "GitHub organization ownership" in the original checklist is translated to MuseHub collaborator/ownership throughout — see the Decision Log entry in the main checklist. Most of this section is Gabriel-only actions (root AWS/Namecheap access, billing contacts, recovery paths) that I cannot perform or verify from here — this doc separates what's already verified true from what needs Gabriel to actually do it.⚠️ Scope update (2026-08-08): the team sharing deploy responsibility grew from 2 people (Gabriel, Aaron) to 5 (+ interns Sol, Toby, Ben). See
runbook-deploy-onboarding.mdfor the access-tier decision (interns are staging-only) and why the current shared AWS credential should not be handed to the interns as an interim measure.
Verified today
- Aaron (
aaronrene) already haswritecollaborator access on both themusehubandmuserepos onstaging.musehub.ai, invited bygabriel— confirmed viamuse hub collaborator list. This is the MuseHub-native equivalent of GitHub org membership, and it's already in place for code collaboration. It does not cover AWS, Namecheap, or infrastructure access — those are separate systems with no shared-access story yet. - The
musehub-infraAWS IAM user is scoped narrowly — confirmed via repeatedAccessDeniedoniam:*,sso:*,route53:*,cloudtrail:*,guardduty:*,budgets:*(see Section 0 doc). This is a good sign: whoever provisioned it did not hand it broad permissions. - I have no visibility into AWS IAM Identity Center —
sso-admin list-instancesis denied for the only credential available here. I can't confirm whether Identity Center exists or whether Gabriel and Aaron have separate human identities in AWS today. Needs Gabriel to check directly in the AWS console (as root or an admin identity), not something I can determine via CLI.
Cannot be verified or performed from this environment
Everything below requires either AWS root/admin console access, Namecheap account access, or GitHub org settings — none of which this environment has credentials for. Listed here as an explicit action list rather than silently left unchecked.
| Area | Action needed | Who |
|---|---|---|
| Domain ownership | Confirm musehub.ai is registered to a company account, not an individual's personal Namecheap login |
Gabriel |
| AWS billing/account ownership | Confirm billing contact and account root email are company-controlled, not tied to one person's personal email | Gabriel |
| AWS human identities | Check whether IAM Identity Center exists; if not, this blocks Section 3 too — create separate identities for Gabriel and Aaron with MFA | Gabriel |
| Sole-recovery-path audit | For each of: Namecheap, AWS, MuseHub, DNS, database, production secrets, billing, backups — confirm at least two people/paths can recover access | Gabriel |
| Company-controlled email | Confirm infra accounts (AWS root, Namecheap, Cloudflare) use company email addresses, not personal ones | Gabriel |
| Joiner–mover–leaver procedure | Doesn't exist yet — needs to be written once access model is decided | Gabriel + Aaron |
| Quarterly access review process | Doesn't exist yet | Gabriel |
| Break-glass procedure | Doesn't exist yet — depends on knowing what "glass" there is (AWS root? Namecheap? Both?) | Gabriel |
| Ownership-per-area recording | AWS admin, DNS/certs, deployments, DB admin, incident response, billing, backups — no owner assigned to any of these yet beyond "Gabriel does everything" | Gabriel |
Independent-operation test (per the checklist's explicit ask)
The checklist asks to test — not just grant — that Aaron can independently sign in to AWS, inspect production, deploy staging, approve/deploy production, inspect logs/alarms, restore from backup, and update DNS. None of this is possible yet because:
- Aaron has no AWS identity today (unverified, pending Gabriel's Identity Center check above).
- Deploying staging today means running
bash deploy/push.sh stagingfrom a laptop with themusehub-infraAWS credentials in~/.aws/credentials— a shared credential, not an individual one. This is exactly the "no shared AWS access keys" anti-pattern the checklist opens with. - There are no logs/alarms to inspect yet (Section 12 is still open).
- There is no backup to restore from yet (Contradiction 2 in Section 0 — needs resolving first).
- DNS is on Namecheap; Aaron's access there is unverified.
This section cannot be closed out until Section 3 (Identity/IAM) and Section 10 (automated staging deploy) exist — right now "deploy access" and "AWS access" are the same shared secret key, which is the opposite of what this section requires. Flagging the dependency explicitly rather than pretending it's independently solvable.
What I did not do
I did not attempt to create AWS IAM Identity Center users, invite Aaron to AWS, or change Namecheap/Cloudflare account settings from here. Those are consequential, hard-to-reverse identity/access changes on shared infrastructure — exactly the kind of action that needs your explicit go-ahead, not something to do speculatively while sweeping the checklist.