One Truth, Many Agents: How an MCP Server Controls My Knowledge Vault

Anyone building AI agents for businesses today often defines their rules in the prompt. But the longer a conversation lasts and the more information accumulates, the easier it becomes for the original rules to fade into the background.

I worked the same way for a while. The knowledge vault I described in the first part of this series was exposed to agents as a file tree. The rules were documented in the manifest and in the preceding system prompts. It worked. Most of the time. And “most of the time” is not good enough to satisfy a customer, or myself.

Agreements only hold as long as the agent follows them

A prompt is a request. It applies to a model, within a context window, for a session. When a new client is added, the request has to be repeated. Once the context window fills up, the conversation history is compressed. Individual rules or important details can be lost in the process. And an agent that has been given direct access to a mounted file system does not even need to follow the request. It can open the file anyway.

I was able to observe this myself. Rules I had written into the context several times were no longer present after a few tool calls. It was not a model trying to annoy me. Context simply is not a place where rules reliably survive.

In organisations, the problem multiplies. Each team maintains its own version of the prompt, the versions gradually diverge, and when something goes wrong and someone asks which rule was in effect, nobody can answer. What is missing is a place where the rule is enforced, regardless of who is working with the system.

What the server does, the prompt would otherwise have to do

I now have my own server sitting between the agents and the vault. It speaks MCP, the Model Context Protocol. The standard, originally developed by Anthropic, is now under the umbrella of the Linux Foundation and is supported by platforms such as ChatGPT, Gemini and Microsoft Copilot. So I did not need to invent my own protocol. I did, however, need to build my own server. Many well-known Obsidian MCP projects require a running desktop app together with a local plugin. They are unusable on a Linux root server running containers without a graphical interface. Generic file-system servers, on the other hand, do not know the architectural and writing rules of my vault. My server therefore runs headlessly, works directly with the Markdown files and enforces the vault’s rules itself.

Through this interface, the agent no longer gets raw file access. Instead, it gets domain-specific tools with fixed response schemas. Rather than blindly overwriting entire files, it updates specific sections under a heading without damaging code blocks. It manages metadata and tags separately, and checks for orphaned notes or archives entries only after checking backlinks. With every write operation, the server also handles what was still a behavioural rule in the manifest in the first article:

Check locks: First check whether another actor has an active lock file, then protect the subsequent update of the wiki index with a separate file lock.
Enforce layers and required fields: Check whether the path is allowed to be written to at all and whether required metadata, such as unique IDs, is present.
Record provenance: Log which actor, which path, which content ID, which trigger (related_to) and when.
Keep things in order: Update the full-text and wiki indexes. References can be checked specifically for broken links.

From an architectural perspective, this is a change of pattern. Without this control layer, the agent would have to orchestrate the steps itself: check locks, modify the file, update the log and refresh the indexes. If the model forgets a step or does not follow the right sequence, the vault can drift out of sync. With the server, a single tool call starts the process. The write rules are already in the code, and the server then takes care of logging and index maintenance. The model no longer has to keep these processes coordinated itself.

Rules are thus moving out of text instructions and into the interface. An interface enforces them consistently, even in the middle of the night and even for an agent I only connect next week. One side effect is that the prompt gets shorter, because I no longer have to explain in the model’s context the processes that the server handles. Once you have removed several pages of writing rules from a system prompt, you do not want to put them back.

Rules that cannot be bypassed

As described in the first part, my vault has a clear separation of concerns: a raw layer for immutable sources, a wiki layer for processed knowledge, and a system layer for rules and operations, alongside folders for ongoing project work. Once ingested, the source layer is sealed.

A few days ago, I wanted to update an outdated research note in the source layer. I had good reasons, I was the system operator, and I gave the instruction directly to my agent in chat. The server rejected the write operation anyway: RAW_IMMUTABLE. Locked layer, no exceptions. A prompt might have been persuaded by my admin role; the code simply does not care who I am. If a source is outdated, a new note or a synthesis is created in the wiki. The original evidence remains untouched.

The prerequisite is that agents no longer have direct file-system access and that all access goes through the server’s tools. To prevent an agent from bypassing these controls through its own tools, the server protects its infrastructure with a denylist. Neither the write log, the lock files, the central wiki index nor the Obsidian configuration can be changed through agent tools or manipulated using search and replace. The server writes the log; the agent is not even allowed to touch it through the interface.

In addition, the server maintains a separate log trail for each actor, so agents working in parallel cannot overwrite each other’s entries. For an organisation, this means agent actions can be traced through their logs without having to hope that the model keeps its own books correctly. Previously, this was a promise in the manifest. Now the server performs the logging and protects the log against changes through the agent interface. A prompt could never provide that guarantee.

One vault, all agents, the same truth

What I underestimated at first was how the control path scales with the clients. In my setup, continuously running background agents (Hermes profiles) operate on the Linux server, alongside my local Hermes agent on my laptop and interactive clients such as Claude and Antigravity. They all work with the same knowledge base.

Each client starts the same MCP server code as its own process, with its own actor identifier (VAULT_ACTOR). Logging is kept separate for each actor. Before a write operation, the server also checks whether another actor has an active lock file, and separately protects updates to the wiki index with a file lock. The binary search index lives outside the synchronised folder. The Markdown files and their associated log and index files are transferred between the server and the laptop, while simultaneous edits to the same file on both machines remain the responsibility of the file-synchronisation mechanism. An additional agent therefore does not have to implement the vault’s rules again; it simply gets the same interface.

The manifest from the first article describes what the rules are. The shared server implementation ensures that they are enforced in the same way for every client. This gives the one-to-many problem in agent-based IT a defined layer where it can be addressed.

MCP is not a security guarantee

Now for the honest part. A standard that unifies interfaces also unifies the attack surface. OWASP (the Open Worldwide Application Security Project) now maintains its own Top 10 for MCP risks. Two attack paths need to be distinguished.

The first path targets the client through third-party servers or manipulated configurations. Invariant Labs has demonstrated how manipulated tool descriptions (tool poisoning) can trick an agent into disclosing confidential information. With MCPTox, researchers systematically investigated such attacks and found significant weaknesses in the agents they tested. A case involving Cursor, known as MCPoison, which has since been fixed, also showed how manipulated MCP configurations could lead to code being executed with the user’s privileges.

The second path concerns the knowledge base itself. A prompt injection in a web page or email the agent reads can induce unwanted write operations if the agent has uncontrolled file-system access.

What matters, then, is not whether an agent uses MCP, but how its access to the underlying data is controlled. Blindly connecting third-party MCP servers introduces a supply-chain risk. And giving agents direct access to files without a control layer does not make the attack surface smaller; it merely makes it less visible. I want to emphasise this point: the standard itself is not the security solution. But it provides a defined interface where I can control access to my knowledge base, including path restrictions, layer locks and a denylist. The decisive factor remains that agents have no uncontrolled access path around the server. A policy only works if every relevant access goes through the control layer. Otherwise, it remains a recommendation.

The cost: building, testing and operating it

A layer like this does not build itself. I built the server myself, and it is tested continuously. More than 400 automated checks run with every change, and one in five of them specifically tests the rules, locks and boundaries, not just the basic functionality. On top of that come ongoing operations and the discipline of deciding in advance what each new tool should allow an agent to do.

Anyone who does not want to operate this layer themselves can use a platform where the provider enforces the rules. That is a legitimate choice. In my opinion, most problems arise from the middle ground: agents are given broad access to important directories, while a long prompt merely reminds them to be careful.

The next part of this series will look at semantic extensions: what happens when knowledge bases grow so large that structure and full-text search alone are no longer enough?

The server is open source: github.com/nakielski/obsidian-mcp

An agent that is allowed to do anything is not a colleague; it is a risk.

How do you control your agents’ access to central knowledge bases: through trust in the prompt, external control systems, or your own control layer?