Describe the feature or problem you’d like to solve

MCP can currently authenticate with:

• Personal Access Tokens (classic or fine‑grained) ✨
• Soon 🚀: OAuth 2.0 device‑code flow via Non PAT auth method #132

Both approaches depend on credentials that are bound to a human account.
In enterprises(including ours) PAT creation is often blocked, and a device‑code token still requires a privileged “service user” to stay alive.
That leaves 24 × 7, org‑wide automation brittle and out of step with GitHub’s own security guidance.

So, neither option is ideal for a headless, fleet‑wide MCP deployment.

Visual cheat‑sheet (PAT vs device‑code vs GitHub App installation):

Proposed solution

Allow GitHub App installation‑token (server‑to‑server) authentication.

• install the App at org/enterprise scope with the minimum perms MCP needs (contents:read, metadata:read, etc)
• store only the App’s private key in AWS Secrets Manager / KMS
• at runtime MCP signs a short‑lived JWT → exchanges it for a 60‑minute installation token → refreshes automatically
• audit events appear as github‑app/mcp‑server

Benefits

• zero human coupling – no PATs, survives re‑orgs and off‑boarding
• short‑lived creds – ≤ 60 min window if a token leaks
• governance – admins can see/change App permissions & repo list in one click
• clear audit trail – bot traffic is obvious (github‑app/…)
• future‑proof – aligns MCP with GitHub’s move away from long‑lived personal tokens

Additional context

Suggested implementation approach

1. add --auth=github-app flag
2. read APP_ID, INSTALLATION_ID, private‑key path/env var
3. generate JWT (RS256) → POST /app/installations/{id}/access_tokens
4. inject token into existing GitHub client; transparently refresh on HTTP 401/expiry

Architecture sketch of MCP + GitHub App flow:

Happy to help spec out more, test, etc - just let me know what’s useful 🙌