Nacre is a self-hosted knowledge index for AI agents, where permission is part of retrieval rather than a filter bolted on after it. An agent acts for a person and reaches only what that person may read: the access check runs inside the index traversal, so results are never trimmed afterwards. Connect over MCP or REST, run it with Docker in two minutes, keep every document on your own machine. Apache 2.0 - and a live demo where one query gives three people three different answers.
What we're building
Vector search is solved. What isn't: making sure an agent querying a company index sees exactly what the person behind it is cleared for — and being able to prove that to an auditor.
Nacre is a context layer, not another company assistant. No chat product, no end-user portal: just the index, the permissions, and two doors into them — MCP for agents, REST for applications. The admin console exists so you can see precisely what a given principal can.
Try it before reading further. The demo stand publishes two logins on its front door — https://demo.nacre.work. Sign in as the engineer and as the contractor, ask the same question, and watch one of them find the contract number while the other gets nothing: not a shorter list, nothing. The filter runs inside the index traversal, so for them the query never reached the document.
Or connect an agent in one command:
claude mcp add --transport http nacre https://playground.nacre.work/mcp
The first call comes back 401 naming its RFC 9728 document and the client walks discovery, registration and a consent screen from there. Six tools — search, list_layers, get_document, ingest_status, ingest_document, delete_document — and when you approve a connection you set its ceiling: which layers, and whether it may write at all. A search client that cannot delete a document is the default, not a setting you have to find.
Why "Nacre"
Mother-of-pearl is brittle aragonite platelets stacked in layers — orders of magnitude tougher than the mineral itself, because a crack stalls between the layers instead of running through. The value is in the arrangement, not the material. Your documents already exist, in Drive and Confluence and folders nobody has opened since 2023; nothing we do makes any single one of them better. The arrangement is the product.
And nacre shimmers without being transparent: light enters the stack, bounces between boundaries, and every angle gets a different answer — while nothing passes straight through. That is the whole product. Every agent and every person gets the cross-section their permissions carve out, and not one line more.
What that means in the code
Permissions are part of retrieval, not a filter over it. Access filtering happens inside the index traversal, so top_k returns k permitted results rather than k minus whatever got stripped afterwards. That goes into the schema on day one; it cannot be retrofitted.
A failed permission evaluation denies. There is no "couldn't compute it, let it through" path — not in the resolver, not in the cache, not in a degraded mode.
"No permission" and "no such object" are the same answer. Otherwise enumerating identifiers tells you which documents exist, which is its own leak.
Self-hosted by default. Docker Compose, your perimeter, your models, no phone-home. The one exception is opt-in and named in the docs in those words: route embeddings to a hosted vendor and that text leaves your installation.
Apache 2.0. Two commands to a working console: https://nacre.work/quickstart
How are you handling this today? The three answers I keep hearing are post-filtering the results, building one index per audience, and hoping the prompt holds. I would like to hear a fourth.