How Obsidian MCP limits access to your vault

Obsidian vaults can hold project notes, architecture decisions, and private working context. Connecting an AI agent to a vault can make those notes available, but unrestricted filesystem access can expose files or operations beyond the configured vault.

Obsidian MCP supports local stdio connections and remote MCP clients over Streamable HTTP. Its repository documents several controls:

1. Vault path isolation. PathGuard checks vault-relative paths and rejects absolute paths, ../ traversal, null bytes, and symlinks that escape the configured vault. The repository includes tests for these cases.
2. Scoped permissions. The server separates vault:read, vault:write, vault:delete, and vault:developer capabilities. A read-only vault rejects note-creation, editing, and deletion operations. Remote clients authenticate with bearer tokens checked against SHA-256 hashes using timing-safe comparison.
3. Destructive-operation controls. Move and delete operations require the appropriate permissions. Administrators can set ENABLE_DESTRUCTIVE_TOOLS=false to remove those tools from MCP registration. The flag defaults to true, so teams that do not need destructive operations should turn them off explicitly.
4. Local and remote deployment. Stdio works with local MCP clients. For remote clients, the project documents Streamable HTTP behind a TLS reverse proxy with scoped bearer authentication. Remote access needs careful configuration, especially when a vault contains sensitive notes.

These controls narrow the operations available to an agent. They do not replace reviewing access scopes, protecting tokens, or testing the deployed configuration. Start with read-only permissions when an agent only needs to search and reference notes.

See the HOL plugin listing and source repository for setup instructions and the test suite.