# Workbench Data, Rights, Security, and Safety Workbench trust is a continuous boundary from browser or native shell through domain services, jobs, providers, storage, exports, and deletion. This page collects the common controls; each domain remains responsible for stricter rules around its own media, people, claims, learning records, generation, payments, builds, and external tools. ## Trust boundaries ```mermaid flowchart LR C[Untrusted client/source] --> E[Trusted edge] E --> A[Identity, tenant, grants, policy] A --> D[Domain service and records] D --> W[Workers and model/tool providers] D --> X[Exports and integrations] D --> P[Projections, search, analytics] D --> B[Backup and recovery] ``` Data crossing any arrow is authenticated where possible, authorized in resource context, validated to a bounded schema, purpose/rights checked, minimized, attributed, observable, and assigned a retention/deletion path. ## Tenant isolation and authorization - Resolve tenant and actor at a trusted boundary; do not honor arbitrary client tenant ids or derive authorization from a route name. - Every system-of-record query, object-storage key, job, cache, index/graph projection, event, export, and audit record carries explicit tenant/resource scope. - Apply permission filters before counts, facets, suggestions, search ranking, graph traversal, and existence checks. - Re-evaluate access when opening shared links, accepting suggestions, executing jobs, downloading exports, and receiving provider callbacks. - Keep personal, project, team, tenant, support, and operator roles distinct. Break-glass access is time-bounded, justified, audited, and reviewed. - Test negative cross-tenant and cross-role matrices in services and deployed journeys; hiding a control in the client is not enforcement. ## Untrusted files, URLs, archives, and parsers Workbench sources can contain hostile media, documents, archives, models, plugins, project files, DCC scenes, fonts, scripts, and metadata. Intake uses allowlisted schemes and destinations, size/count/depth/time limits, magic-byte and container validation, malware/quarantine, sandboxed parsing, safe preview, and output validation. URL import defends against SSRF, redirects, private/link-local metadata networks, DNS rebinding, oversized streams, authentication leakage, and unsafe content types. Archive handling prevents traversal, symlink/hardlink escapes, decompression bombs, device files, executable startup hooks, and nested-limit bypass. A thumbnail, transcript, waveform, model conversion, DCC probe, or link preview is still processing untrusted input. Derived files inherit quarantine and rights state until explicitly admitted. ## Models, prompts, agents, and external tools Source text and metadata are data, not instructions. Model adapters isolate system policy from untrusted content, constrain tool availability and argument schemas, validate outputs, preserve provider/model/prompt-policy versions, and withhold when evidence or configuration is insufficient. An assistant or agent proposal cannot bypass: - tenant/resource authorization; - step-up and exact confirmation where required; - domain preconditions and concurrency/version checks; - rights, safety, review, budget, capacity, and release policy; - idempotency, audit, provenance, and independent verification. DCC/engine bridges and remote hosts are particularly sensitive. Commands are allowlisted and capability-negotiated; project roots and artifact paths are scoped; archives and subprocess arguments are validated; host identity, version, lease/fence, output hashes, and receipts are recorded. ## Sensitive domain data | Domain | Examples requiring explicit handling | | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Isis | Prompts, reference assets, model inputs/outputs, safety decisions, provider credentials, lineage, and unreleased creative work. | | Metis | Learner identity, progress, assessment, accommodations, cohorts, feedback, credentials, and inferences about proficiency. | | Yemaya | Copyrighted/authorized sources, depicted people, transcripts, pose/performance annotations, gameplay telemetry, creative research, and model-derived analysis. | | Veritas | Confidential sources, embargoes, claims/counterclaims, drafts, legal/review state, corrections, and publication credentials. | | Euterpe | Recordings, voices, sessions/stems, collaborators, unreleased music, plugins/licenses, and rights splits. | | Aja | Reference/capture video, face/body/voice, skeleton and pose data, performers' consent, motion-derived assets, and biometric-adjacent inference. | | Bellona | Proprietary projects/scenes, build artifacts, remote-host access, source-control references, engine credentials, logs, and customer toolchains. | Collect the minimum needed for the declared purpose. Do not silently reuse production or customer data for evaluation, training, demos, or support. ## Rights, consent, and policy Rights are versioned records tied to source, person/party, purpose, territory, time, allowed transformations, sharing/export, model use, and evidence. Consent is not a generic boolean; it identifies who consented, to what, when, under which notice/version, and how withdrawal propagates. Policy decisions are attributable and explainable. A UI surfaces why a source, model, action, result, export, or share is unavailable and what supported remedy exists. It does not invite workarounds around rights or safety boundaries. ## Provenance, signing, and audit Provenance identifies sources and transformations across revisions, jobs, providers, models/tools, reviewers, outputs, publications, and exports. Hashes prove bytes; signatures bind a manifest and signer; neither proves the truth of an annotation, claim, or model result. Audit records security- and governance-relevant facts without duplicating sensitive payloads. Secrets, raw tokens, full prompts/source text, protected media, payment credentials, and unnecessary personal data are redacted at the producer, not only in dashboards. ## Retention, expiry, deletion, and backups Every record class declares system of record, purpose, retention, rights-expiry behavior, legal/policy holds, projections/caches, backup treatment, and deletion verification. Rights expiry can disable use before the retention window ends. Deletion can preserve a minimal tombstone/audit fact while removing content. Deletion fanout is idempotent and follows references to blobs, derivatives, indices, embeddings, graph edges, caches, job artifacts, provider copies, and exports. The system says pending, blocked, or residual when that is the truth. Backups have tested reclamation/expiry rules and never become an indefinite shadow archive. ## Export, sharing, and publication - Re-authorize on access and export, not only when the project was created. - Manifests enumerate versions, hashes, provenance, licenses/rights, exclusions, schema/tool versions, recipient/purpose, and expiry. - Public or external publication has review, disclosure, takedown/correction, delivery receipts, and replay-safe idempotency. - Shared links are scoped, expiring/revocable, non-enumerable, and do not leak resource existence after revocation. - Sanitized exports exclude secrets, internal paths, hidden prompts, unrelated tenant data, unsafe active content, and restricted source bytes. ## Threat and incident coverage Security testing includes tenant/role matrices, session fixation and CSRF, injection, SSRF, archives and path traversal, parser sandbox escapes, malformed media, prompt injection, tool/agent authorization, provider callbacks, webhooks/replay, idempotency and concurrency races, secrets/log leakage, export/signature verification, deletion fanout, backups/restore, and remote DCC host controls. The most detailed worked example is the [Yemaya Study Workspace threat model](../../../docs/proposals/yemaya-study-workspace/threat-model.md) and its [incident runbooks](../../../docs/proposals/yemaya-study-workspace/incident-runbooks.md). Shared platform game-day, isolation, leak, restore, withdrawal, and fencing scanners live under `libs/oshun/workbench-kit/tools`. ## Review checklist - What data and people are involved, and what purpose/rights permit it? - Which trust boundaries and external systems does it cross? - How are tenant, actor, resource, version, and idempotency established? - What happens for unauthorized, malformed, malicious, expired, deleted, partial, offline, duplicated, reordered, or conflicting input? - Which evidence, provenance, disclosure, audit, retention, and deletion records result? - Can an export, log, metric, notification, or error leak content or existence? - Can rollback or restore reintroduce deleted, revoked, or unauthorized data? - Which automated test proves each enforcement rather than only its UI label?