Security model guide

ROST is built around tenant isolation, seat-scoped authority, vault-backed credentials, server-side tool guards, and human approval for durable decisions.

Security principles

• Tenant data stays tenant-scoped.
• Seats own work; people and agents occupy seats.
• Credentials are vault references, never raw secrets in prompts or logs.
• Tool calls are checked server-side and audited.
• Agents recommend and draft; humans approve durable decisions.
• Accepted knowledge changes by supersession, not silent mutation.
• Skills are reusable procedures, not authority. They are versioned immutably, can declare tool dependencies, and are loaded only after assignment; they never grant tools or override the Charter.

What ROST stores

ROST stores operating-system state for each tenant so humans and agents can run the company with an audit trail. The main stored categories are:

• Company setup, onboarding state, members, roles, invites, and tenant settings.
• Compass answers and versions, Responsibility Graph seats, occupancies, Steward links, Charters, signed permission manifests, goals, Signals, Frictions, tasks, decisions, Sync briefs, and events.
• Agent setup state, model/run metadata, work orders, run diagnostics, transcript references, token and cost usage, Skill assignments, and immutable Skill activation records.
• Tool-call audit rows: tool id, canonical guard result, safe argument summaries, outcome, evidence labels, escalation state, and error linkage.
• Integration records, OAuth connection metadata, channel/binding metadata, notification preferences, notification delivery errors, and connector readiness/test results.
• MCP token metadata, Runner metadata, runner-pairing state, and revocation state. Raw token material and runner bearer secrets are shown only at issuance when the flow requires it and are not retrievable from normal reads.
• Credential records that contain vault references and safe metadata only. Raw API keys, OAuth refresh tokens, tenant Anthropic keys, Slack tokens, Google tokens, and REST connector secrets stay outside Postgres in the configured vault path.
• Uploaded or generated documents and bounded extracted context when a user intentionally adds them to onboarding, Compass, Charter, or reference workflows.

Do not store raw passwords, OAuth tokens, API keys, full .env files, session cookies, private signed URLs, or credential payloads in prompts, Skill files, command JSON, issue comments, logs, or reference docs. If a workflow needs a secret, route it through credential ingress and store a vault reference.

Access and isolation

Every tenant-scoped product record is scoped by tenant_id, and database policies are written so one tenant cannot read another tenant's data through normal application access. Server-side tenant context comes from trusted server-side authority, not from client-supplied tenant ids: browser and CLI user sessions use authenticated Supabase claims plus membership, MCP sessions use the authenticated MCP token record, and runner sessions use the authenticated runner credential record.

Human access is role-based through tenant membership:

• Owners can administer tenant settings, integrations, members, MCP tokens, agent setup, and credential flows.
• Stewards and members usually act through their seat occupancies and assigned responsibilities; some tenant-scoped setup, read, and credential workflows are also available to active tenant members when the command authorization layer allows them.

Seat Steward accountability is separate from the tenant membership role named steward. A Seat Steward is the human accountability chain for an agent seat and receives escalations for that seat, but being named as a Seat Steward does not silently grant a model permission to act.

Agent authority is seat-scoped even when the machine credential is broader. A seat-scoped MCP token can act only as the seat it was minted for. A paired runner authenticates as a tenant machine credential, claims tenant work orders, and receives seat-scoped work context plus a temporary seat-scoped MCP token for the claimed order; the runner bearer credential itself is not a single-seat credential. Tenant-admin MCP tokens are broader: they can reach workflows in the tenant-admin command surface, bounded by command authorization and guards. Reserve them for setup and administration, and prefer the narrowest scope that can do the job.

Local clients such as Claude Code, Codex, OpenCode, and Cursor may receive command/resource output through MCP. ROST enforces token scope, schemas, tenant isolation, and redaction on the output it returns; the local client and provider account control local transcript storage, telemetry, and model-provider handling. For that model-bound path, use the ai-model-data-handling-guide.

Credentials and integrations

Credentials are never authority by themselves. A connected Slack, Google, REST, Anthropic, or future integration credential can be used only when all required checks pass:

1. The actor is authorized for the tenant and command. 2. The Seat Charter and signed permission manifest allow or escalate the tool. 3. The tool handler exists and validates its input schema. 4. The integration is connected for the tenant and has an active credential reference. 5. Any extra binding exists, such as a Slack channel binding, REST host/method/path policy, or provider-specific setup requirement. 6. Human confirmation is complete when the command or credential flow requires it.

Tool selection is never authorization. A selected tool in setup records the requested permission; live execution still goes through the server-side guard, and the system is designed to write a tool-call audit row for every execution attempt. Standard agent audit reads do not return argument summaries or secret material.

Audit trail

ROST is designed to explain who or what changed operating state:

• The event log is append-only. Corrections are new events, not edits to old events.
• Decisions are human-decided records. Agents can draft or recommend, but durable decisions require a human.
• Charters, Compass versions, and accepted knowledge change by supersession instead of silent overwrite.
• Agent runs, work orders, tool calls, Skill activations, notification failures, and integration tests leave diagnostic records that can be inspected without exposing raw secrets.
• Product-visible server/integration/runtime failures are recorded in error_logs when tenant context is available; pre-auth or tenant-less failures fall back to structured server logging.

When reporting evidence to a human, summarize the relevant fields and include stable ids only when they help trace the record. Do not paste raw secrets, full provider responses, full prompt text, or broad exports into status updates.

Retention and support access boundaries

ROST keeps the records needed to operate, secure, troubleshoot, audit, and improve the product. This guide does not promise a fixed deletion schedule, zero retention, regional residency, HIPAA readiness, or staff-access workflow beyond what is explicitly stated in the customer contract, product settings, or public legal pages.

Staff and support access should be treated as operationally sensitive. The current public posture is conservative: authorized personnel may access customer information when reasonably needed to operate, secure, or support the service; investigate abuse, reliability, or security issues; comply with law; or respond to a customer request. Google user data and information derived from Google APIs remain subject to the Privacy Policy's Google user data limits: humans may access that data only where the customer gives explicit permission for support, for security, to comply with law, or as required to operate the Google-connected features the customer uses. Do not claim that staff technically cannot access customer data in all circumstances unless that control is included in a separate written agreement and has been implemented for that account.

When support access is needed, use the least data needed to diagnose the issue, prefer tenant-visible product evidence when available, redact secrets, and do not export broad customer datasets for routine support. Avoid asking customers to paste secrets, OAuth tokens, full provider responses, or raw mailbox/spreadsheet content into chat, tickets, issues, or docs. If a customer asks for deletion, retention, legal hold, DPA, BAA, regional processing, customer-visible staff access logs, break-glass approval, or staff-access commitments, escalate instead of improvising an answer.

Retention language by category:

• Workspace operating records such as graph, Charter, goal, Signal, Friction, task, Sync, run, event, and tool-call records are retained while the workspace is active so the product can show history, audit trails, and diagnostics.
• Connected-service credentials are revoked when an integration is disconnected or the account is closed. Normal reads return credential metadata and vault references, not raw secret material.
• Security, audit, event, diagnostic, and abuse-prevention records may be retained after an account or workspace deletion request is completed when needed for integrity, legal compliance, dispute resolution, or service protection.
• Product-improvement analytics use only aggregated or de-identified data under the public Privacy Policy and Terms. Aggregated or de-identified derived metrics may be retained after account closure because they no longer identify a workspace.
• Google user data and information derived from Google APIs stay under the Privacy Policy's Google user data limits and are not included in cross-customer product-improvement analytics.

Deferred enterprise controls are not current promises: customer-visible staff access logs, formal break-glass approval, support-access approval workflows, customer-managed retention windows, full self-serve data export/deletion, regional data residency, DPA/BAA commitments, and HIPAA readiness require separate implementation or contract review before being promised.

The public Privacy Policy and Terms of Service are available at /privacy and /terms before sign-in and from the authenticated app chrome.

Those legal pages state that ROST may analyze aggregated or de-identified data about usage, setup patterns, agent outcomes, and operating metrics to improve product features, defaults, templates, recommendations, safety checks, and reliability. They also state that ROST does not sell customer data, does not share one customer's workspace data with another customer, and does not use identifiable customer content to train generalized AI models. Google user data and information derived from Google APIs stay under the Privacy Policy's Google user data limits and are not included in cross-customer product-improvement analytics. Keep those limits intact when explaining product improvement analytics, and escalate legal/security questions about contracts, deletion, regulated data, or customer-specific commitments.

For model-bound data questions — including what cloud, mcp_session, or runner sends to an AI provider, what BYOK changes, and what local clients can store or transmit — read the ai-model-data-handling-guide before making a provider, retention, HIPAA, ZDR, or no-training claim.

Where to read next

• Read the ai-model-data-handling-guide for model-provider, BYOK, local-client, MCP-session, and runner data paths.
• Read the tool-access-and-vault guide for credential ingress, vault references, permission manifests, and tool execution boundaries.
• Read the mcp-and-cli-guide for token scope, installation, rotation, and local-agent setup.
• Read the runner-guide for runner pairing, local credential storage, bearer-token handling, and queue boundaries.

Agent guidance

Never infer permission from the user's wording, a local client configuration, a connected credential, a Skill, or a locally available tool. Check the tenant, role, seat occupancy, Charter, signed permission manifest, command schema, confirmation state, and server response. When in doubt, escalate with the evidence and the narrow question a human must decide.