Storage Permissions in Local, Vault, and Drive Workflows

이 상세 자료는 아직 한국어로 번역되지 않아 영문 원문을 표시합니다.

GA 공개 출처와 지원 범위

Status: GA
Component: Thegram Vault and Google Drive integration
Deployment: Cloud service https://vault.thegram.one/; Google Drive connection
Applies to version: Latest
출처 확인일: 2026-10-25
Owner: thegram-one/thegram-vault
Public evidence: thegram.one/llms.txt
thegram.one/agent-memory/
Basis: The public documentation describes Vault storage and separately authorized Google Drive access; it does not state a version for either storage path.

출처 확인은 실제 계정 설치·기기 동작·서비스 상태의 검증을 뜻하지 않습니다.

Start by checking the exact destination

Before opening, importing, or editing a document, identify the canonical copy and the storage identity that owns it. A local file, a Thegram Vault mount, and a Google Drive mount are different destinations; signing in to one does not grant access to another. Inspect the full mount key, path, reported access level, and selected account before writing.

For client setup, use the shared local setup or cloud setup guide. This page explains what the storage boundaries mean; it is not a substitute for provider consent or a role grant.

Local files: the person and filesystem control access

A local .gram file is governed by the operating-system account and filesystem permissions of its location. Desktop local mode can work without an account or network request. That convenience does not synchronize the file to another device or make it shared. Keep the original in the chosen folder, and do not move it to a cloud location just to make a client show it. The file contains document content and revision history; search indexes and other derived views are not a replacement for it.

If an agent connection is enabled, its read/write mode is a separate local app permission. Choose Read when the agent only needs context; enable Read and Write only when that is the intended capability. The app must be running for its local connection. See local setup for the current host-specific flow.

Thegram Vault: authorize an account, then use the returned mount

A Vault mount is account-backed service storage. Authentication, organization membership, the effective role, and a mount's reported access level determine what that caller can do; a document's .gram fields do not grant access. A viewer or read-only mount cannot be made writable by changing the requested path. Vault document writes are limited to top-level .gram documents: use a path such as @mounts/<vault-id>/project.gram, not an invented nested path. The literal <vault-id> must be the identifier returned in the mount key.

After connection, call gram_projects and copy the exact mount key from its response. The key (for example, @mounts/<id>) is the stable path prefix to use; do not substitute a display name or guess an ID. Confirm the destination account and access level before each requested write. If a write is denied, stop at that destination; do not silently copy to another mount.

A cloud account may receive a default writable Vault during first discovery if none exists. That is account setup, not authorization to create project records or import private content. Confirm the user's requested document and destination separately. See cloud setup for the connection path.

Google Drive: provider consent and folder scope are separate

A Drive mount is based on the Google account and Drive scopes authorized for that integration. In the documented drive.file flow, the app can access files it created or that the person explicitly opened; it is not unrestricted Drive browsing. A Vault owner can separately link a company account or Shared Drive for members acting through Vault roles. Personal Drive and Shared Drive remain distinct places, and the mount's returned key and exact path identify the destination. Drive mounts can expose folders, unlike Vault's top-level document-path restriction, but that does not make every file or Shared Drive writable. Follow the mount's actual access report and provider response.

A Drive OAuth grant is not a Thegram account role, and a Thegram login is not a Google authorization. Revoke or narrow provider access through the provider's own account controls; changing a .gram record cannot change OAuth scopes or Drive sharing.

Handle updates as conditional writes

For a local Core or Vault update, read the current document and use the revision and hash observed from that same state as the conditional-write precondition. Core records an accepted change as a new revision; Vault validates the document and conditionally publishes a new file head. If the precondition is stale, reread the current version, compare both edits, and construct a fresh intentional change. Do not replay a stale patch unchanged or replace the file by hand. Drive file-head checks are best effort rather than an atomic compare-and-swap, so a concurrent writer can still race; inspect the resulting provider state and reconcile instead of claiming stronger protection.

For a Drive-backed write, claim remote persistence only when the returned synchronization state is synced. A successful local Core write or request receipt does not by itself prove that Drive has synchronized it. If synchronization is pending or failed, retain the source and report the actual state. Do not retry into a different mount to make a failed sync appear successful.

A safe choice in practice

Choose local storage when one person needs a file on that machine and explicitly owns its filesystem location.
Choose a Vault mount when the intended account and organization role provide the required access; verify the exact top-level mount path.
Choose Drive when the authorized Google account and mounted folder are the intended shared source; verify personal versus Shared Drive scope.
For any remote destination, inspect its key and access report, use a current revision/hash, and read back the result. Report provider sync only when the provider confirms it.

Limits and evidence

These paths have different trust boundaries. A public web renderer is an ephemeral document-rendering service, not a mounted storage location or sync target. An iOS Vault/Drive document is a read-only downloaded copy in the reviewed client flow; it does not imply editing the provider's file. Exact role, OAuth, and synchronization behavior is determined by the currently deployed service and provider response, not this guide.

Source: Vault authorization and storage contract

Internal Vault service contract reviewed for account identity, mount roles, path constraints, conditional writes, and synchronization; not a public service-availability claim.

Reference: https://github.com/clab-one/thegram-vault/blob/main/docs/SPEC.md

Source: Google Drive permissions model

Google Drive API documentation on file permissions and access behavior.

Reference: https://developers.google.com/drive/api/guides/about-permissions

Source: Core history and conditional-write contract

Thegram Core source-history contract for History/6 revisions, CAS writes, state replay, and journal provenance.

Reference: https://github.com/clab-one/thegram-format/blob/main/spec/source-history-render.md

Source: Client storage boundary sources

Internal Desktop, iOS, local agent, and cloud MCP sources reviewed for local connection permissions and read-only downloaded client flows.

Source and renderer evidence

Canonical source SHA-256: 2d702ff2a44621bcd546a704d11a92d8efedadb9142a3fe525228e06cfd1d817
Selected revision: r2 · sha256:3ec45b78308d4f91ed202848a365b166a72dffa3b57049269600dece600c568e
Local renderer: configured local Thegram renderer · API thegram-web-render/1
Core source: git+https://github.com/clab-one/thegram-format.git?rev=b16489e1d0d77d38f82d2f61776524737aa31557#b16489e1d0d77d38f82d2f61776524737aa31557

Canonical source: storage-permissions.gram

안내와 다른 점이 있나요? 문서 오류 신고 · 문제 해결
이메일은 직접 검토해 전송하세요. API key나 비공개 문서 내용은 보내지 마세요.