Hi HN — this release came from a problem I kept seeing when teams put RAG into production: retrieval and authorization are usually separate systems.
Vector databases rank chunks by similarity, not by who is asking. Once documents with different access levels share an index, retrieval can return chunks the user was never authorized to see. Nothing is broken — every component is doing exactly what it was designed to do.
The usual fixes all have drawbacks:
- One index per role doesn't scale to relationship-based permissions. * Post-filtering after top-k hurts recall and still retrieves restricted content. * Prompt instructions aren't security boundaries. In Authorizer 2.3.0 we added Zanzibar-style Fine-Grained Authorization (FGA) and an MCP server so agents can enforce the user's permissions rather than the agent's service account permissions.
The demo uses Qdrant + Authorizer FGA:
- Ask FGA which documents a user can access. 2. Push that authorization data into vector search as a pre-filter. 3. Retrieve only authorized chunks.
Same question, different users, correctly different answers.
FGA is new in this release, and I'd especially love feedback on the relationship model, schema ergonomics, and scaling strategies for large allow-lists.
I'm also curious how others are solving permission-aware RAG today: OpenFGA, OPA, homegrown filters, something else?
Repo: [https://github.com/authorizerdev/authorizer](https://github.com/authorizerdev/authorizer)
Demo: [https://github.com/lakhansamani/qdrant-rag-llm-example](https://github.com/lakhansamani/qdrant-rag-llm-example)
Blog: [https://blog.authorizer.dev/permission-aware-rag-authorizer-...](https://blog.authorizer.dev/permission-aware-rag-authorizer-openfga-qdrant)
Happy to answer questions about the architecture, Zanzibar tradeoffs, MCP integration, or why we put this inside the auth server rather than a separate service.
Comments URL: [https://news.ycombinator.com/item?id=48555648](https://news.ycombinator.com/item?id=48555648)
Points: 1