VaultGuard Sync (Cloud): permissions and share links

VaultGuard permissions answer two questions independently: who may enter a vault, and what may that person do at a path inside it.

Access layers

Layer	What it decides	Example
Organization role	Organization-wide administration	A normal member cannot manage billing or every user.
Vault membership	Whether the person may enter one vault	A finance member need not belong to the engineering vault.
Vault role	Baseline actions inside that vault	Viewer, Editor, or Admin.
Path rule	Exception for a folder or file	Viewer can edit /Projects/Status/** but not the rest of the vault.

Use the simplest layer that produces the intended result. Too many overlapping path rules are harder to explain and audit.

Recommended role workflow

1. Add the user to the organization.
2. Add them to the intended vault only.
3. Choose the narrowest workable vault role.
4. Add a folder rule when a whole knowledge area differs.
5. Add a file rule only for a true exception.
6. Verify allowed and denied actions with a disposable note.

Pattern examples

Pattern	Meaning
/Projects/*	Direct children of Projects only.
/Projects/**	Projects and every descendant.
/Handbook/Benefits.md	One exact note.

More-specific rules can override broader rules. A denial wins when equally specific allow and deny rules conflict. Administrator bypass behavior depends on the organization's administrator-restriction setting.

Explain an access result

Right-click a file or folder and choose the VaultGuard permission explanation. The explanation should identify the selected vault, the relevant membership or role, matching rules, and the resulting action. Use the permissions graph for a wider view across users and paths.

Create a Cloud share link

1. Right-click a file in Obsidian.
2. Choose VaultGuard Sync: Copy share link.
3. Send the link through an approved team channel.
4. The recipient opens the link and allows it to hand off to Obsidian.
5. VaultGuard verifies their current vault membership and read permission before revealing or opening the file path.

A share link is a pointer, not a bearer capability. It does not contain a decryption key and does not bypass permissions.

What recipients need

• VaultGuard Sync installed and enabled.
• A signed-in account in the same organization.
• Membership in the source vault.
• Read permission for the shared file.
• The correct local Obsidian vault open or available.

If any authorization gate fails, the link does not reveal the protected path.

Manage and revoke links

Run VaultGuard Sync: Manage share links to review active links and revoke those no longer needed. Revoking a link prevents future resolution through that pointer. It does not remove the recipient's underlying vault membership or retract content they already opened or exported.

Share-link safety

• Do not present a VaultGuard link as an anonymous public share.
• Send links only to intended teammates.
• Use expiry when the workflow offers it and the collaboration is temporary.
• Revoke links when a project or channel closes.
• Remove vault membership separately when the person should lose access to the vault itself.
• Review share creation, resolution, denial, and revocation in the audit log.

Share links and the hosted share bridge belong to VaultGuard Sync (Cloud). Self-Hosted Community Edition collaborates through membership and permissions and does not provide this feature.