Security & trust
A clear boundary for code, coordination data, and access.
A procurement-oriented statement of what the product does today, what depends on deployment choices, and what is not yet certified.
Architecture and data boundary
SyncStaff uses a smart-client, metadata-server design. Source files, parse trees, local indexes, embeddings, and repository credentials remain on the machine running the coding agent. There is one exception by default: when an agent declares an interface change, the adapter sends the matching call-site lines, up to 200 characters each, so the change can be reviewed. Setting SYNCSTAFF_BLAST_INCLUDE_CONTEXT=0 on the agent machine sends paths and line numbers only. Server processes hold no state of their own; durable data lives in PostgreSQL. The server runs scheduled jobs, including Chief of Staff reviews and connected-app sync, and does not parse repositories or build semantic indexes.
The server stores the data needed to coordinate work: account and team identifiers, project names, agent/session identity including the machine hostname, checkout path, and operating-system username, repository-relative file paths, intent summaries, leases, tasks and board records, decisions, audit events, interface-change summaries, and call-site lines. If you use these features, it also stores uploaded documents, Slack conversation text, and records from connected apps such as mail subjects, people, and short previews. Intent text and file paths may reveal business context, so customers should treat all of this as confidential.
Encryption and credentials
Hosted traffic uses HTTPS/TLS in transit. Self-hosted installations bind to loopback by default; publishing a hostname enables automatic TLS and requires authentication. Database-at-rest encryption depends on the storage platform selected for the hosted or self-hosted deployment and should be confirmed in the applicable order form or infrastructure configuration.
Human browser sessions and agent credentials are separate. An agent token is scoped to its team/project authorization, returned once during enrollment, and stored locally with owner-only file permissions. GitHub sign-in requests identity, not repository access. Model-provider keys are server-side configuration and are not sent to coding agents.
Tenant isolation
Authenticated requests resolve a tenant from the credential before application work begins. On the hosted service, tenant-bearing PostgreSQL tables carry a team identifier and enforce row-level security; application authorization adds role and project checks. A signed-in person can select only organizations their account belongs to, and an agent token stays bound to its own.
Self-hosted authentication-off mode is intentionally single-tenant and must not be exposed to the internet. The installer refuses the public-domain path unless sign-in is configured.
Models and subprocessors
Deterministic coordination, leases, board policy, and local code analysis require no model provider. When a model key is configured on the server, model-assisted arbitration runs by default and the relevant coordination records go to the configured provider. Chat and the daily Chief of Staff review also send board text, questions, and excerpts from connected apps. The repository and local index are not sent. Anthropic and OpenAI-compatible endpoints are supported; deployments choose which model each role uses.
The hosted service uses Vercel for the website, a virtual private server for the API and PostgreSQL database, GitHub for identity, Stripe for billing, PostHog for product analytics and masked session replay, Resend or Postmark for email, the configured model provider, and optional Slack, Telegram, and connected-app integrations. The definitive subprocessor list and hosting region for a hosted order must be supplied with the contract; this page does not substitute for that deployment-specific schedule.
Retention, deletion, and auditability
Coordination state and its audit history are durable in PostgreSQL so decisions can be reconstructed; an organization admin can delete a project, which also removes its history. Nothing is deleted automatically when a trial or subscription ends, and there is no self-serve organization deletion or export yet. SyncStaff currently does not publish a universal hosted retention or deletion SLA. Procurement should record required retention periods, backup retention, deletion timing, and export requirements in the order form or data-processing agreement. Self-hosted customers control the database volume, backups, and deletion directly.
History records attribute material coordination events, escalations, approvals, and resolutions. Founder access across organizations is limited to named accounts and is not yet separately logged. Application logs are designed to avoid bearer tokens and request arguments, though edge access logs can include URLs, so customers should still apply their own log access and retention controls when self-hosting.
Support and incident response
Security reports and suspected incidents should be sent through the support channel named in your agreement. Include the affected tenant, approximate time, and request or event identifiers; do not send credentials or source code. Revoking credentials, suspending a tenant, disabling model calls, and preserving audit evidence are manual operator steps today.
A public security contact and contractual severity/response-time schedule are not yet published. Buyers who require a defined notification window, 24×7 escalation, vulnerability-disclosure address, or data-residency commitment should make those explicit contracting requirements before production use.
Certification status
As of October 30, 2026, SyncStaff does not claim SOC 2, ISO 27001, PCI DSS, HIPAA, FedRAMP, or another independent security certification. No penetration-test attestation is represented by this page. Architecture controls and automated isolation tests are engineering evidence, not a certification.
This statement is intentionally precise about current gaps. Procurement teams should request the latest security questionnaire, test evidence, subprocessor schedule, and roadmap rather than infer compliance from product design.