Protected assets
- Source code and files inside configured project roots
- Agent, terminal, OAuth, and speech-provider credentials
- Thread history, prompts, tool activity, and permission decisions
- The ability to execute commands as the Trit service user
- Immutable artifact revisions, sandboxed previews, artifact capabilities, frozen and live shares, copied share images, recipient email restrictions, and unguessable share tokens
- Artifact hub contents: every owner’s artifacts, comments, and audit events; the hub proxy credential; the hub session key; and each workspace’s hub credential
Trust boundaries
The host user, configured ACP agents, configured shell commands, and explicitly managed 1MCP instances are trusted. Browser users of the full workspace must be authenticated through local loopback mode, a validated Cloudflare Access JWT, or a private owner-filtering VPN proxy plus a secure browser session. In private-proxy mode the VPN gateway and reverse proxy are trusted identity issuers; the proxy requires an encrypted restricted backend transport. An ACP session receives a temporary capability limited to its thread and project for artifact operations. The optional share listener is a separate read-only boundary: a random token authorizes a link-only thread or artifact share, while an email-restricted share also requires a Cloudflare Access JWT with the dedicated share audience and an email that matches one stored recipient. Remote icon, speech-provider, and Cloudflare endpoints are untrusted networks. An artifact hub trusts its owner-filtering proxy as the identity issuer, like private-proxy mode, and additionally requires each workspace’s bearer credential to match the proxy-asserted owner. A hub-connected workspace treats hub responses as untrusted. Hub owners are trusted not to attack each other through the hub service itself; folder rules separate their private artifacts.
Primary risks
- Forged reverse-proxy identity or cross-origin browser requests
- Project-root escape through symlinks, filesystem callbacks, or terminal working directories
- Command execution outside the intended permission decision
- Repository-controlled Git hooks or filters executing during source-control operations
- Secret disclosure through configuration, logs, raw ACP events, icons, or provider context
- Malicious or compromised dependencies and release artifacts
- Irreversible database changes during an upgrade
- An owner reading another owner’s private hub artifacts or comments, a workspace credential or browser session used as a different owner, or an agent exceeding its owner’s hub permissions
- Share-token disclosure, recipient-identity confusion, reasoning, activity, or artifacts disclosing secrets, live links disclosing later history or revisions, views that include unintended or raw event data, malicious artifact HTML escaping its sandbox, or share routes that reach workspace capabilities
Controls
- Explicit authentication modes, JWT signature/audience verification, and origin checks
- Private-proxy mode: loopback-only listener, per-instance proxy credentials, twelve-hour signed host-only Secure/HttpOnly/SameSite cookies, exact Host/Origin checks, authenticated WebSocket upgrades, no-store responses and disabled public sharing
- Canonical project roots, symlink escape rejection, and bubblewrap-scoped ACP terminal requests
- Project-scoped repository validation, fixed Git command arguments, configured-remote membership checks, non-interactive credentials, disabled repository hooks (
core.hooksPath), bounded discovery concurrency and command output, and worktree-content-aware stale-status mutation checks - Durable permission decisions and thread-scoped repeated approvals; optional per-agent
permissions.autoApprovefor trusted agents - Environment indirection for credentials and redaction of browser-facing configuration
- Lockfiles, reviewed install scripts, dependency scanning, CodeQL, secret scanning, SBOMs, checksums, and build attestations when supported
- Automatic update staging verifies the exact GitHub release-workflow Sigstore identity, CT log, Rekor entry, and immutable release checksums
- Separate loopback-only share listener, hashed 256-bit tokens, allowlisted normalized visible-event fields, explicit exclusion of raw ACP payloads and hidden configuration events, explicit frozen or live mode, exact selected artifact revisions in frozen thread snapshots, bounded or optional expiration, immediate revocation, optional exact-email JWT checks against one or more stored recipients, restrictive response headers, and no workspace API or WebSocket mounts
- Immutable artifact revisions with byte and count quotas, temporary thread-and-project capabilities, sandboxed HTML without same-origin privilege, also when a content URL is opened directly (
sandbox allow-scriptsin the response policy), response and document content security policies that block network access, safe Markdown conversion, escaped code rendering, and owner-only share creation - Artifact hub: separate entry point without workspace modules, loopback listener, owner-bound sessions signed with a hub-only key that the proxy does not hold (this stops offline forgery with a leaked proxy credential; the proxy still asserts identity and can start a session as any owner), exact origin rules for API and content, bearer credentials bound to the proxy-asserted owner, folder authorization on every route with
404for foreign private items, author-only artifact changes in private trees, shared-tree changes by every owner who is a person with immutable revisions and no move out of the shared tree by a non-author, owner-only archive, service owners that change only their own artifacts in their configured folders and never comment, bounded quotas, audit events, validating workspace clients with timeouts and response limits, and CLI output that drops control and invisible characters (bidirectional controls, zero-width characters, Unicode tags) from hub text - Numbered migrations, consistent backups, versioned releases, health checks, and rollback
Non-goals
Trit is not a hostile multi-tenant sandbox, a privilege boundary between users on the same Unix account, or a safe way to run untrusted ACP implementations. It must not run as root or expose an origin listener to the internet. Link-only thread and artifact shares are bearer capabilities: anyone who obtains an active URL can read its frozen snapshot, current live view, exact artifact revision, or current artifact revision.