Vault Bridge: a permissioned MCP middleware for agentic workflows

TL;DR: Giv­ing LLMs access to a knowl­edge base is easy. Giv­ing them scoped, per­mis­sioned, read/write access with­out hand­ing over the keys to the king­dom is hard. Vault Bridge is a Rust mid­dle­ware lay­er that sits between an Obsid­i­an LiveSync data­base (CouchDB) and an MCP client, enforc­ing pol­i­cy-as-code boundaries.

The code is avail­able at https://github.com/nareto/vault-bridge.

The Architecture

Vault Bridge treats Obsid­i­an as the front-end and CouchDB as the source of truth. It builds a derived index in Post­greSQL (with option­al pgvec­tor embed­dings) and expos­es REST and MCP inter­faces to agents.

The MCP sur­face is delib­er­ate­ly constrained:

• read an exact vault file with get_vault_file;
• retrieve con­text with query_notes, query_base, get_neighbors, and list_tags;
• write through create_vault_file and edit_vault_file.

Instead of a gener­ic “ask my vault” black box, autho­rized clients read exact Mark­down files. They can also use query_base to exe­cute a sub­set of Obsid­i­an Bases-style table pro­jec­tions, return­ing struc­tured JSON rows direct­ly from the vis­i­ble work­ing set.

Policy-as-Code Access Boundaries

My vault con­tains tech­ni­cal specs, pub­lic drafts, and pri­vate notes. Vault Bridge han­dles read/write iso­la­tion on the serv­er, not through prompt etiquette.

Each token maps to a named con­text with explic­it read, cre­ate, and edit rules. A restrict­ed cloud-fac­ing con­text looks like this:

mcp_tokens:
  cloud-agent:
    context: non_personal

contexts:
  non_personal:
    read:
      - deny:
          path_prefix: "00Journal/"
      - deny:
          tags_any: ["personal"]
      - allow:
          default: true
    create:
      - allow:
          default: true
        add_tags: ["ai-created"]
    edit:
      - allow:
          tags_any: ["ai-editable"]Code language: YAML (yaml)

This pol­i­cy applies across all tools. A client can­not bypass its view by switch­ing from a seman­tic search to an exact file read. The bound­ary is explic­it, review­able, and enforced before the con­tent reach­es the agent.

Proof of Concept: The Daily Scout Data Flow

For more than 100 con­sec­u­tive days, I have run a dai­ly work­flow called Dai­ly Scout through Vault Bridge.

Instead of gen­er­at­ing a sta­t­ic newslet­ter from a user pro­file, Dai­ly Scout queries Vault Bridge for recent note diffs to map my active work­ing set. It research­es rel­e­vant exter­nal resources (papers, tools, archi­tec­tures), and writes a for­mat­ted Mark­down file back to my inbox via create_vault_file.

The agent does not own the note sys­tem. It per­forms a bound­ed read/write oper­a­tion over a secure inter­face, leav­ing a review­able arti­fact in my exist­ing workspace.

Why this matters outside Obsidian

This archi­tec­ture pat­tern maps direct­ly to enter­prise engi­neer­ing teams.

Most teams have run­books, archi­tec­tur­al deci­sion records, and sup­port his­to­ries spread across inter­nal sys­tems. The tempt­ing pitch is to “con­nect every­thing to an AI agent.” In real­i­ty, doing that with­out a strict mid­dle­ware lay­er is a com­pli­ance and secu­ri­ty risk.

The hard­er, more valu­able work is decid­ing which sources are admis­si­ble, expos­ing them through a pre­dictable MCP inter­face, con­strain­ing what the agent can change, and return­ing the out­put to exist­ing human review loops.

If your team is try­ing to give agents access to inter­nal knowl­edge with­out giv­ing them unre­strict­ed author­i­ty, I would be hap­py to com­pare notes.