Public vs Private — auth-tier on one Hussh wiki
How the Hussh wiki serves anonymous public readers and the authenticated owner from one MCP server and one reader, including HCT bearer auth, OAuth 2.1 + PKCE, tool/resource/prompt tiering, sanitization rules, and content guards.
TL;DR: One repo, one canonical markdown corpus, one MCP server, one
Next.js reader. The MCP decides per request what the caller can see and do.
Anonymous callers get visibility: public pages plus 8 public-safe read tools.
Authenticated callers get the full wiki, 17 tools, private operating resources,
private prompts, edit UI, drafts review, and artifact capture. Same URLs, same
routes, different visibility envelope.
Status as of 2026-05-26: Live in production at https://wiki.hushh.ai
and https://mcp.hushh.ai. Anonymous public MCP reads use
https://mcp.hushh.ai/mcp; authenticated owner access uses
https://mcp.hushh.ai/mcp/auth to force OAuth or bearer-token auth before
tool listing. Runtime reads use the hosted GCS/Firestore serving plane, while
MCP writes mirror to wiki Drive source and publish derived snapshots without
per-write Git commits. Git is maintained by the scheduled export mirror.
Why one stack
The wiki has two jobs:
- Preserve private operating memory.
- Publish Hussh's public product, R&D, and architectural voice.
Two separate stacks would create drift: public pages would become copied
fragments, private pages would keep evolving elsewhere, and agents would need
to learn two surfaces. One stack keeps the corpus coherent. visibility is a
per-page property; authorization is a per-request property.
The boundary
The public/private guarantee has five layers:
- Frontmatter — every wiki page declares
visibility: public | private. Missing visibility defaults private in code. - MCP page filter — read/list/search/relation/history/diff tools call the same visibility logic; private pages look not-found to anonymous callers.
- MCP capability filter — anonymous
tools/list,resources/list, andprompts/listexpose only public-safe capabilities. Direct anonymous calls to private capabilities returnauth_required. - Reader gating — the Next.js reader fetches through MCP. Anonymous browser visitors never get private page data or edit affordances.
- Drive boundary — the dedicated wiki Shared Drive is the source and
artifact home. Private pages and private artifacts never receive
anyone with linkDrive permissions; public artifacts must receive per-file reader access on the canonical file or the save drafts instead of creating a blocked public preview.
The important architectural rule: the reader is not trusted to protect private content. The MCP is the capability boundary.
Tool tiers
Anonymous callers see 8 tools:
wiki_readwiki_searchwiki_listwiki_relationswiki_lintwiki_historywiki_diffwiki_recent_public
Authenticated callers see those 8 plus:
wiki_recent_changeswiki_writewiki_patchwiki_linkwiki_deletewiki_promote_visibilitywiki_capturewiki_artifact_savewiki_artifact_delete
wiki_recent_changes is auth-only because fleet-wide git history can leak
private page existence through paths or commit subjects. wiki_recent_public
exists for public widgets and strips commit subjects by design.
Resources and prompts
MCP resources and prompts are also tiered. This closes an easy-to-miss leak
class: a private page can be hidden from wiki_read while still being exposed
through a resource if resources are not filtered.
Anonymous resources are limited to public-safe server/protocol/connector metadata. Private resources such as the full wiki index, non-negotiables, schema, glossary, and business knowledge map require auth. Private operational prompts such as ingest, brand audit, Fund A status, and who-is workflows also require auth.
What is public
Public pages are the pages that can stand alone without private operational, financial, legal, family, or counterparty detail. Today that mostly means:
- Product pages for One, Kai, Nav, PCHP, iBrokerage, and product artifacts.
- R&D concepts such as BYOA, LLM Wiki pattern, artifact capture, public/private surfaces, wiki-as-app architecture, search/scaling, and Material/UI patterns.
- Fund-strategy frameworks only when written as public intellectual voice, not as fund status or LP/private operations.
- One founder-approved public profile page.
Everything else defaults private.
Sanitization rules
A public page must not reveal:
- Personal contact details or private people rosters.
- Personal or work email addresses.
- Counsel communications or internal legal details.
- Entity identifiers, tax IDs, filings, or formation-sensitive status.
- Private raw-source paths.
- Private Drive file IDs or Drive links that require sign-in.
- Consent tokens, bearer tokens, client secrets, or other auth material.
- Specific private financial figures, LP details, allocations, or operating cash details.
- Private wiki markers that only make sense inside the operating corpus.
The wiki_promote_visibility tool scans a page before private-to-public
promotion and refuses matches unless the caller explicitly forces after manual
review.
Private source Drive
WIKI_DRIVE_PRIVATE_SOURCE_ID points at the restricted Shared Drive used for
private source material. Its root layout is:
- Private markdown source workspace.
- Private source captures that should not become public URLs.
- Private files that do not map cleanly to a page.
- Private artifact copies created by MCP.
This Drive is for Kushal, Manish, and the delegated runtime user. It is not a public serving surface. Public pages are derived outputs; Drive source files stay private unless a public artifact save explicitly creates a separate public Drive copy.
How a page moves public
- Author as
visibility: private. - Sanitize the page until it can stand alone publicly.
- Call
wiki_promote_visibility(path, to: "public"). - Fix any scanner findings.
- On success, the change publishes to the serving plane and the public reader can serve the page. The next scheduled export mirrors the source markdown to Git.
Reverse promotion to private does not need a scan.
Relations
- Wiki-as-app architecture — runtime stack this boundary sits inside.
- LLM Wiki pattern — public/private wiki evolution context.
- Storage architecture notes — private Drive and hosted serving-plane contract.
Enterprise architecture streamlining boundary
- Current repo truth: private people/contact/SOW/partner artifact pages stay private unless a visibility promotion passes the sensitive-content scan and removes private body text.
- North-star direction: public pages may include north-star language only when labeled as current repo truth, north-star direction, not shipped/not implied, and source docs.
- Not shipped / not implied: no private partner contacts, emails, tokens, local paths, HCTs, or developer tokens should appear in public/shareable enterprise architecture material.
- Source notes: internal enterprise architecture notes and founder-language matrix.
Sources
- Wiki-as-app architecture — runtime stack this boundary sits inside.
- LLM Wiki pattern — public/private wiki evolution context.
- MCP implementation notes — per-request auth and tool/resource/prompt tiering.
- MCP implementation notes — public/private resource listing and public connector metadata.
- MCP implementation notes — public/private prompt declarations.
- MCP implementation notes — visibility parsing and per-page filter.
- MCP implementation notes — public promotion scanner.
- MCP implementation notes — public-safe recent activity buckets.
- Reader implementation notes — clean
/wiki/...route mapping.