An agent with a knowledge graph of the whole codebase: who decides which parts it may read?

[javmann100]

I maintain mnki, an open-source verification layer that sits in front of an MCP server and checks each tools/call against the calling agent's delegated authority, with a signed evidence list per decision. It wraps any server unchanged, so it works with codebase-memory-mcp as it is.

Your server indexes an entire repository into a graph and answers structural questions in a handful of tokens, which is exactly why teams will point it at their most sensitive code. The question I keep meeting: when a contractor's agent and a core team's agent share one index, who decides which services, directories or Cypher queries each may touch, and where is the record? Do users ask you for scoping like that, or is the index treated as all-or-nothing?

Twenty minutes would help me a great deal; a reply here is plenty. Integration paths: https://mnki.com/docs/integrations. Thank you for the server; 162 vendored grammars in one static binary is a remarkable piece of engineering.

[DeusData]

Thank you for raising the access-scoping question and for explaining your project. CBM is a local code-intelligence tool; sharing access to a graph and deciding which users or agents may access which source are separate design concerns. We should not imply that indexing a repository establishes a multi-user authorization policy.

We are not committing to an external authorization-service integration or dependency here, and we have not reviewed or validated the wrapper you linked. I will leave this discussion open for concrete local-use requirements, but this should not be read as an endorsement or an integration commitment. Thanks again for bringing the question to the community.

[DeusData]

Thank you again for raising access scoping. Following up: there is no integration decision or validation of the linked wrapper to report. A concrete local scenario—who shares the index and which operations should be allowed or denied—would help keep this discussion focused on requirements. The earlier caution about not inferring multi-user authorization from an index still applies.

[DeusData]

Thank you again for the discussion. If access scoping remains a requirement, a concrete local scenario identifying who shares the index and which operations need restriction would help.