VaultGuard Sync (Cloud): security and privacy guide

This guide states the public security boundary for the managed service in plain language. It is not a certification or a claim that VaultGuard is zero-knowledge.

File content protection

Supported file bodies are encrypted by the plugin with AES-256-GCM before upload. The managed service stores ciphertext and uses KMS-backed, server-managed key material to authorize recovery and time-bounded key leases.

Because authorized service-side recovery can unwrap keys and process plaintext transiently, VaultGuard Cloud is inside the trust boundary. Do not describe the managed design as operator-inaccessible, zero-knowledge, or technically unable to recover content.

Metadata

The service can process operational metadata needed for synchronization and authorization, including filenames, relative paths, sizes, versions, memberships, permission rules, key references, audit data, and device or network metadata. File-body encryption does not make this metadata invisible.

Local at-rest protection

VaultGuard can encrypt supported vault files on local disk under a per-device local key after recoverable remote durability is established. Obsidian receives readable content through the protected adapter path.

Excluded paths, Obsidian and plugin caches, metadata, Local Project Memory Mode content, and safely pending files can remain plaintext. Protect the device with full-disk encryption, a strong login, OS updates, and appropriate endpoint controls as well.

Transport and sessions

VaultGuard uses HTTPS with TLS 1.2 or newer, with TLS 1.3 where negotiated. Authentication sessions and key leases are time-bounded. Limited offline work can continue while a valid lease exists; offline access is not indefinite.

Permissions and revocation

Every protected content operation is scoped to a vault and evaluated against membership and permission rules. Revoking a user prevents renewed authorized access after the relevant session and lease boundaries.

Revocation cannot delete plaintext a user already downloaded, exported, photographed, or copied while legitimately authorized. Treat access granting as a data-sharing decision.

Audit

Server-observed authentication, sync, permission, share, agent, and administrative operations emit audit events. The audit trail supports review of successful and denied actions; it does not capture every local action inside Obsidian.

Audit records can contain private metadata. Redact IP addresses, device strings, identifiers, and file paths before publishing screenshots or support materials.

AI data movement

When a user asks a remote AI provider to read or change a note, the content needed for that turn is sent to the selected provider. VaultGuard permissions govern which vault data the tool can obtain; the provider's own privacy, retention, and account terms govern what happens after transmission.

Recovery

Version and deleted-file recovery are permission-checked and audited. Recovery depends on retained versions, key availability, permissions, and backup state. It is not a promise that every historical state can always be restored.

User responsibilities

• Enable two-factor authentication.
• Keep passwords, provider keys, recovery codes, and lease tokens out of notes.
• Use the narrowest organization, vault, path, and agent permissions.
• Protect endpoint devices and backups.
• Review share links, invitations, denied events, and administrator activity.
• Report suspected account compromise promptly to support@vaultguard.cloud.

For architecture-level security review, contact VaultGuard for the current evidence appropriate to your plan and intended deployment. Public product documentation is not a substitute for a contractual security assessment.