What this is

A knowledge base is a named collection of documents an organisation uploads. People are granted a base; their agents inherit exactly that and no more. Retrieval returns passages with the document each came from and how closely it matched.

The base is the permission boundary, not the document. That is a design decision worth stating rather than discovering. Per-document permissions sound finer grained and behave worse: a search is a top-k, so filtering after it means a narrowly permissioned reader gets worse answers rather than fewer results. If you need a split, make a second base.

It is not a better embedding model. The retrieval here is ordinary, and a competent team builds the same pipeline in a fortnight. If you want the best possible answer quality over a large messy corpus, buy something specialised.

What is hard to assemble is one identity, one policy and one log across the models your agents call, the tools they use and the documents they read. That is what this is for.

Inside a chat completion. Add one header to a call you already make. No second base URL and no second credential.

curl https://api.vatan.one/v1/chat/completions \
  -H "authorization: Bearer $VATAN_API_KEY" \
  -H "x-vatan-knowledge: handbook" \
  -d '{"model":"openai/gpt-4o-mini","messages":[{"role":"user","content":"How much parental leave do I get?"}]}'

As a search endpoint, when you want to build the prompt yourself.

curl https://knowledge.vatan.one/v1/search \
  -H "authorization: Bearer $VATAN_API_KEY" \
  -d '{"query":"parental leave","bases":["handbook"],"limit":5}'

As MCP tools, so an agent already connected to your tool servers gets knowledge_search in the same tool list, governed by the same grants and landing in the same call log.