Insight: The gateway is not the authority

Classification

Architecture Note / Technical Article

Core insight

A single MCP endpoint does not imply a single authority boundary. The useful model separates:

1. Client authentication — who may enter the MCP portal.
2. Capability routing — which upstream tool plane receives a call.
3. Upstream identity — which GitHub identity and scopes execute the call.
4. Execution authority — which actions governance actually permits.

Proposed article

Working title: The Gateway Is Not the Authority

Explain the real DogBuild dogfood architecture: one portal, three GitHub capability planes (core, Projects, and Actions read-only), and why applying a portal policy is different from configuring upstream authentication.

Include:

• an accessible architecture figure;
• the distinction between portal policy and upstream Authorization: Bearer <PAT>;
• how tool names/capabilities select the correct upstream;
• why read-only and write-capable planes should remain separate;
• the canary evidence: issue lifecycle, Projects status changes, Actions reads, and webhook delivery;
• the failure that exposed a stale listener/control-parser assumption;
• the remaining hardening: dangerous-tool curation, dedicated least-privilege identity, cleanup, and local recovery documentation;
• a clear evidence boundary: dogfood proof is not production/security certification.

Publication safety

Do not publish tokens, service-token credentials, owner email addresses, Cloudflare account identifiers, private screenshots, or exact secret-storage fields. Describe the architecture and lessons, not the credentials.

Brand review

• Engineering depth: strong architecture and security-boundary reasoning
• Original insight: grounded in an implemented multi-upstream MCP setup
• Practical value: prevents a common gateway/authentication mental-model error
• Evidence: real read/write/read-back and webhook canaries
• Recommendation: APPROVED WITH IMPROVEMENTS — publish only with explicit evidence and security boundaries

Acceptance criteria

• Article added under insights/
• Accessible architecture diagram included
• Ask Mantosh knowledge source added
• SEO/card/feed/sitemap discoverability updated through existing generators
• Repository verification passes
• PR links this issue and remains unmerged for owner review

Final actions

• Publish now
• Improve first
• Convert into a project page
• Convert into an article
• Convert into documentation
• Save for later

Start by examining existing articles under insights/ and the repository’s SEO, card, feed, and sitemap generators, then review the verification process. The article is done when it includes the approved architecture content, an accessible diagram, an Ask Mantosh source, discoverability updates, passing verification, and a linked unmerged PR for owner review.