KB Access Control Explainer
Security asks one question after every “AI that knows your docs” demo: whose docs, and at what classification? Most platforms answer with a shrug and a system prompt that says “be careful.” HUMΛN answers with a classification model the Companion cannot violate—even if a prompt tries to coerce it.
This is the explainer for builders wiring MCP clients, operators writing audit checklists, and anyone who has watched an LLM leak a doc it should never have seen.
Two personas, one mechanism
Two people ask about KB access:
- MCP client builder (customer org) — what can the Companion see when their AI client connects via MCP under an org delegation?
- Internal HUMΛN operator — which Internal/FoundersOnly docs can ground answers for the HUMΛN team under a team delegation?
Both share the same enforcement: every KB doc carries a classification, and every delegation token carries the right to read certain classifications. The Companion’s KB layer (@human/companion-kb) joins them at query time. There is no separate “admin override” path.
The four classifications
| Classification | Who can read it | What it contains |
|---|---|---|
| Public | Anyone with kb:read:public (everyone, by default) |
Public KB docs + the Canon RAG corpus + product marketing |
| Internal | HUMΛN team delegations + customer admins under explicit grant | Architecture, implementation status, design decisions |
| ExternalPartner | Designated partner DIDs with kb:read:partner |
Partner-shared docs not yet GA |
| FoundersOnly | Founders’ passports only | Strategic plans, sensitive financials, board materials |
FoundersOnly is never exposed through MCP. The classification check happens before the embedding is retrieved from pgvector—there is no path where an MCP client can query a FoundersOnly doc, regardless of prompt injection cleverness.
What “Public” actually means
When a Cursor user with no org grant asks “how do I add a connector?”, the Companion can ground on:
- The Canon corpus (foundational principles and protocol architecture)
- Public-classified KB docs
- Public AI corpus (
apps/website/public/ai/articles/) - Public OpenAPI and marketing surfaces
That is enough for most integration questions without org context.
The Canon RAG layer is special: it is pre-seeded into every Companion session at the system-prompt level. The Companion knows what HUMΛN is before it answers. That stops the “confabulates because it has no docs” failure mode.
What “Internal” means (and how it’s gated)
With kb:read:internal, the Companion can additionally see architecture deep-dives, implementation status, ADRs, and internal runbooks.
A customer admin can request kb:read:internal for a narrow slice (for example, integration architecture for one connector). They cannot request the full corpus. Grants are least-privilege: explicit, time-bound, scoped.
What “FoundersOnly” means (and why it never moves)
Strategic plans, board materials, sensitive financial models—none of this is reachable from any MCP surface. The Companion does not even know these docs exist when serving an MCP client. Ask for the Series A plan; it truthfully says it does not have access.
Hard wall. Not a soft suggestion.
How org KB plugs in
When an org admin installs a connector (Confluence, Notion, Drive, SharePoint), HUMΛN ingests content into the org’s vector store. Members with kb:read:org see those docs alongside Public Canon. Non-members see only Public.
The same model applies to personal KB—connect your own Notion; other users in the org cannot. The query plan is (Public Canon) ∪ (Org KB if delegated) ∪ (Personal KB if delegated), with a final classification filter before anything leaves the API.
What about prompt injection?
Two defenses:
- Pre-retrieval gate. Classification runs before vector search. Internal embeddings are not in the candidate set for a Public delegation.
- Post-retrieval filter. Even if a doc leaked into candidates, the response builder drops anything above the delegation’s level.
The Companion is not relying on willpower. The platform does not give it the option.
Auditability
Every KB read logs passport DID, delegation ID, doc ID, classification, query, and timestamp. An auditor can reconstruct what any agent saw. The provenance ledger is append-only and signed.
Scroll-stopper: Access control that depends on the model’s manners is not access control—it is a prompt with good intentions.
Practical: choosing a classification
If you publish docs into HUMΛN (connector or KB API):
- Default to Internal unless you explicitly want Public
- Use ExternalPartner for named partners before GA
- Use FoundersOnly only for material that must never reach an LLM
When in doubt, classify up. Declassifying later is easier than recalling a leak.
So that…
…builders know the Companion answers from a delegation-bounded candidate set, operators can prove what was visible, and nobody mistakes “the model refused” for policy. Classification + delegation + audit is the trust model—not training data vibes.
Go deeper
- Product: Companion, What is HUMΛN
- Docs: Introduction, Delegations
- Community: Selective disclosure, Passport as MCP trust, Agents before and after a trust layer