RFC: ghpool as private MCP server — zero-PAT GitHub access for AI agents

[chaodu-agent]

Summary

Explore evolving ghpool into a private MCP server that provides GitHub API access to AI agents without ever exposing a PAT (or any token) to the agent.

Motivation

Current approaches for AI agents (e.g. OpenAB on ECS/EKS) to interact with GitHub:

Approach	Limitation
Fine-grained PAT	Single org only; long-lived; can be exfiltrated
Token Vending Machine	Agent still receives a short-lived token — can be misused during its lifetime
ghpool as MCP Server	Agent never sees any token. All GitHub operations go through MCP tools.

The MCP server approach provides the strongest security boundary: the agent can only perform operations that are explicitly exposed as MCP tools.

Design Goals

1. No PAT required by the agent — Zero tokens exposed to the agent at any point
2. Operation-level access control — Agent can only call MCP tools that ghpool exposes (e.g. create_pr, push_file, list_issues)
3. Centralized audit — All GitHub operations funnel through ghpool, enabling per-operation logging
4. Token management internal to ghpool — ghpool handles PAT rotation, token vending, or GitHub App auth internally
5. Per-agent scoping — Different agents can have different MCP tool permissions
6. No git CLI dependency — Agent does not need git or gh CLI; everything goes through MCP

Proposed Architecture

┌────────────────────────────────┐
│  AI Agent (OpenAB / Kiro CLI)  │
│                                │
│  No PAT, no git credentials    │
│  Only MCP client capability    │
└───────────────┬────────────────┘
                │
                │ MCP Protocol (stdio / SSE)
                │ Tools: create_pr, push_file,
                │        list_issues, post_comment...
                ▼
┌────────────────────────────────┐
│  ghpool (Private MCP Server)   │
│                                │
│  • Tool allowlist per agent    │
│  • Rate limiting               │
│  • Audit logging               │
│  • Internal token management   │
│    (Token Vending / GitHub App)│
└───────────────┬────────────────┘
                │
                │ GitHub API (with internal token)
                ▼
┌────────────────────────────────┐
│  GitHub (repos, PRs, issues)   │
└────────────────────────────────┘

Comparison with Token Vending

	Token Vending	ghpool MCP Server
Agent gets token?	✅ Short-lived	❌ Never
Access boundary	Token scope	MCP tool definition
git CLI compatible	✅ Direct	❌ Needs MCP tool wrapping
Granularity	Installation scope	Per-tool level
Best for	CI/CD, coding agents that need git	High-security, strict audit requirements

Complementary Design

ghpool MCP Server can internally use the Token Vending Machine pattern to manage its own GitHub credentials, achieving both:

• Token never leaves AWS (vending machine)
• Token never reaches the agent (MCP boundary)

Open Questions

• Which MCP tools should be exposed? (CRUD on PRs, issues, files, comments, reviews?)
• Transport: stdio (sidecar) vs SSE (network service)?
• How to handle git push semantics without giving agent git access? (file-based commit API?)
• Per-agent permission model: config file? IAM-based?
• Should ghpool pool multiple GitHub App installations for cross-org?

Related

• Token Vending Machine refarch
• MCP Specification
• Current ghpool functionality (PAT pooling)