vaultbase

Permissions that actually work

Folder-level, file-level, and tag-level RBAC with a deny-wins model. Groups, role inheritance, per-user folders, and the same rules applied to AI agents. No exceptions.

Permission resolution
# Group: engineering (role: editor)
allow editor /engineering/**  # team folder
allow editor /shared/**
allow editor /users/{user}/**  # expands to /users/alice/**
deny  *     /hr/**          # deny always wins
allow reader tag:public      # tag-level grant
/engineering/runbook.md editor
/users/alice/notes.md editor
/hr/salaries.md denied

How it works

Three scoping levels

Permissions can target folders (/engineering/**), individual files (/shared/roadmap.md), or tags (tag:confidential). Folder rules use glob patterns and apply recursively. Tag rules apply to any file carrying that tag, regardless of where it lives in the vault. All three levels compose — a file can match multiple rules, and the most restrictive result wins.

Deny always wins

VaultBase uses a deny-wins resolution model. If any rule denies access, access is denied — even if another rule explicitly allows it. This makes it safe to grant broad access and then carve out exceptions. Add deny * /hr/** and no one outside the HR group can reach those files, no matter what other rules exist.

No implicit access. Users with no matching rules see nothing. This is a closed-by-default system.

Groups, roles, and inheritance

Users belong to groups. Groups have a default role — reader, editor, admin, or agent. Permission rules can override the group role for specific paths. A user in multiple groups inherits the union of all grants, but deny rules from any group still take precedence.

The agent role is purpose-built for AI. It carries the same scoping as any other role but can be further restricted to read-only or specific tool subsets via MCP configuration.

Per-user folders with {user}

The {user} variable expands to the authenticated username at evaluation time. Write one rule — allow editor /users/{user}/** — and every user gets a private folder that only they can write to. Admins can still read. Agents acting on behalf of a user resolve to that user's folder.

This pattern scales to any number of users without adding individual rules.

Example CLI commands

# Create a group with editor role
$ vaultbase group create engineering --role editor
# Grant folder access
$ vaultbase permission add engineering --allow editor --path "/engineering/**"
# Deny HR folder to everyone
$ vaultbase permission add everyone --deny --path "/hr/**"
# Per-user private folders
$ vaultbase permission add everyone --allow editor --path "/users/{user}/**"
# Tag-level read access
$ vaultbase permission add everyone --allow reader --tag public
# Check effective permissions for a user
$ vaultbase permission check alice /hr/salaries.md
denied (deny rule on /hr/**)

Why it matters

AI agents respect boundaries

Agents get the same RBAC scoping as humans. An engineering agent cannot read HR files. A support agent cannot edit engineering docs. No special cases, no leaky abstractions.

Audit everything

Every access — read, write, denied — is logged with user, timestamp, path, and resolution reason. The audit log is queryable via CLI and API for compliance reviews.

Scale without pain

Add 50 people to a group, write 3 rules, and you're done. Per-user folders handle private workspaces. No per-file ACLs to maintain as the vault grows.

Closed by default

No implicit access means a misconfigured rule fails safe. Users see nothing until explicitly granted — the opposite of "public by default" systems that leak data when someone forgets to lock a folder.

Related features

Download VaultBase

Free. Works offline. No account needed.

Open source. AGPL-3.0. Plain markdown files. Export anytime.