Company Brain Refuses to Answer? Need-to-Know Makes AI Check Permissions First

Enterprise AI assistants always face a fundamental question: will it leak the payroll spreadsheet to an intern? Most demo products dodge the issue, but developer Mayur Khan chose to tackle it head-on with Need-to-Know, built at the Graph Hacks hackathon—this company brain's first duty isn't to answer every question, but to figure out who has the right to know what.

The project demo and code are open source. It's built on the graph database FalkorDB and uses a permission chain to constrain every AI response.

The Essence of Access Permissions Is a Graph

In real enterprises, access rights are rarely as simple as "this person can open this file." More commonly, it's a chain like this: Priya belongs to the Support group, Support belongs to All Staff, All Staff was temporarily added to the Drive migration project in 2023, and that project has access to the payroll spreadsheet. No one remembers that last link, and no one can confidently answer "who can actually see this payroll spreadsheet."

And a chatbot that finds answers from all documents turns this hidden chain into everyone's problem. Need-to-Know's solution is to model membership chains as edges in a graph database. In FalkorDB, a single Cypher query can traverse up to 8 levels of nested groups along MEMBER_OF relationships to find everything a person (or an AI agent) can read. The median query time is 0.45 milliseconds—fast enough to run in real time on every question and every agent step. And permissions are never cached, so there's no risk of stale access.

Cypher is a graph database query language led by Neo4j, whose syntax uses ASCII art to depict graph patterns, e.g., (p:Person)-[:MEMBER_OF*1..8]->(g:Group) means starting from a person node and traversing 1 to 8 hops along MEMBER_OF edges. FalkorDB supports a subset of Cypher, which is why the original article can expand a nested group chain in a single query. Unlike traditional SQL, which requires repeated recursive JOINs, Cypher treats "graphs" as first-class citizens, and traversal cost is approximately linear with path length, making sub-millisecond real-time permission decisions possible.

A Brain That "Thinks"

The developer generated a realistic company, Northwind Labs, as a test environment: 211 employees, 9 teams, 19 nested groups, 21 documents and conversations, 3 customers, and 3 AI agents—plus three deliberately planted real-world permission errors.

The entire company graph is drawn in the shape of a brain: leadership in the frontal lobe, customer teams at the back, documents in the memory lobe, AI agents in the cerebellum, and FalkorDB as the brainstem. When you ask a question, a signal starts from you, passes through the groups you belong to, and reaches every document you're allowed to access; blocked documents receive a red signal and stop midway. The animation strictly follows the paths actually used by the database, so it's a faithful representation of the answer-finding process.

Same Question, Different People, Different Answers

Ask as Support intern Priya, "Why did Acme's October invoice increase?" She gets an answer from the pricing policy: the loyalty discount lasts 12 months and doesn't auto-renew, and every fact is tagged with its source and owner. But she won't see contract amounts and invoice records—instead, a locked notice appears: "Contract amounts and discounts. Requires Finance or Leadership access. Contact Arjun Mehta."

Ask the same question as Finance lead Meera, and those hidden lines become real answers. The brain doesn't pretend restricted things don't exist, nor does it leak them—it tells you what's missing and who to ask.

"Why Can I See This?"

Every fact has a button that reveals the shortest group chain behind it, e.g., "Priya → Support → All Staff → Company Handbook." Access is no longer a mystery.

Private Memory for Every Person and Every Agent

The brain remembers questions you've asked before. Each memory hangs on its owner's node in the graph, and every memory query starts from your node. This means there is no path at all from my node to your memories. The demo proves it directly: "Priya has 4 memories, Meera can reach 0."

AI Agents Follow the Same Rules as Humans

Agents are group members just like people, so they get exactly the permissions their groups have. In the demo, the Support Agent and Finance Agent share customer ticket #4821. The Finance Agent adds a note with contract details visible only to Finance. When the case returns to the Support Agent, that note is redacted, so the reply to the customer can't leak it. If the drafted reply does contain finance-private data, the approval step refuses to send it.

FalkorDB is a graph database built on a sparse matrix and linear algebra engine, focused on low-latency concurrent graph queries. It maps graph adjacency to sparse matrix multiplication, so it's often faster than traditional graph databases for multi-hop traversal and path finding, and it's well-suited to scenarios like this where "permissions must be computed on the fly for every question and every agent step." It supports OpenCypher queries, has built-in vector indexing, can be deployed via Docker, and provides multi-graph (key) management commands like GRAPH.COPY—exactly the capability used later for "testing fixes on a copy."

Three Ways to Check Permissions, Only the Graph Is Right

The developer independently rewrote the permission rules in Python as ground truth, then ran 54 askers × 8 questions through three access-check methods. The results are highly convincing:

Access Check Method	Leaks	False Denials	Usefulness
Graph traversal (Need-to-Know)	0	0	100%
Flat permission list (direct groups only)	0	521	37.5%
No check (ordinary document chatbot)	840	0	100%

Graph traversal matched the Python ground truth 100% on all 6,634 (person, passage) pairs. The flat permission list is safe but nearly useless: people can only see 37.5% of what they should. No check is useful but leaked 840 times. Only the graph is both safe and useful, because only the graph understands groups within groups.

Flat permission list refers to an implementation that only checks "whether the user directly belongs to an authorized group"—it doesn't expand nested groups. The consequences are asymmetric: on one hand, it doesn't leak (because it only errs on the side of denial); on the other hand, it blocks many users from content they should see, which is exactly the source of the 521 false denials and 37.5% usefulness in the table. The key difference from graph traversal isn't "whether it's safe" but "whether it understands transitive membership"—the true semantics of enterprise permission chains are precisely transitive.

The Brain Self-Checks

The Health check feature compares "who should be able to open each sensitive document" with "who can actually open it," and found the three planted issues:

• 2026 salary bands table: 211 people can open it instead of 3, all through that forgotten "Drive Migration 2023 (temporary)" group.
• Q3 board update: 34 people instead of 5, through a project group.
• Ravi Kumar transferred from Finance to Engineering but is still in the Finance group. Just this one stale membership unlocks 5 things.

The best part: every proposed fix is first tested on a full copy of the company using FalkorDB's GRAPH.COPY. The brain forks the graph, applies the fix, checks that the right people lost access and that people who should retain access still have it, then deletes the copy. Only after that does a human approve, and the change is saved as a decision record the brain can explain later.

GRAPH.COPY is one of FalkorDB's multi-graph management commands, used to create an independently named copy of a graph within the same instance. In this project, it serves as a "sandbox for permission changes": first copy the entire company graph, apply the fix on the copy, then verify that "people who shouldn't have access indeed lose it and those who should keep access retain it," and finally delete the copy. This fork-test-discard pattern turns permission fixes from irreversible operations into rollback-able experiments, and it's the prerequisite for Health check to safely make recommendations.

Pitfalls and Next Steps

Development wasn't all smooth sailing. FalkorDB can't run natively on Windows, so the developer simply ran everything against a real FalkorDB on GitHub Actions—resulting in 13 tests, benchmarks, container builds, and screenshots of every UI on each push, followed by redeploying the live demo. Answer drift also occurred: initially, any passage mentioning "Acme" ranked highly, so asking about an invoice increase returned a liability cap. Now passages that only match a customer name are discarded, and policy and decision content is prioritized for "why" questions.

Next steps include: connectors to import real groups and documents from Google Workspace, Slack, and Notion; real-time alerts when new sharing suddenly expands access to sensitive content; and time travel—"who could see this document last March?"

Conclusion

Need-to-Know's value isn't in how new its tech stack is, but in how it redefines the trust foundation of a company brain: an AI assistant is only trustworthy once it clearly knows "who is allowed to know what." For anyone building enterprise-grade AI applications, this hackathon project offers a runnable, verifiable, permission-first paradigm.