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 code, parse trees, local indexes, embeddings, and repository credentials remain on the machine running the coding agent. The server is a stateless API layer backed by durable PostgreSQL storage; it does not perform source-code parsing or semantic indexing.
The server receives coordination metadata needed to prevent collisions: account and team identifiers, project names, agent/session identity, repository-relative file paths, intent summaries, leases, tasks and board records, decisions, audit events, and interface-change summaries. Intent text and file paths may reveal business context, so customers should classify them as confidential metadata.
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. Tenant-bearing PostgreSQL tables carry a team identifier and enforce row-level security; application authorization adds role and project checks. A request-supplied team identifier cannot override the tenant bound to the credential.
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. If an administrator enables model-assisted arbitration, the relevant coordination record—not the repository or local index—is sent to the configured provider. Current server configuration supports Anthropic-compatible arbitration; deployments may select or disable model roles.
Service dependencies may include the customer-selected hosting and PostgreSQL providers, GitHub for identity, the configured model provider, and optional Slack, Telegram, or email delivery providers. 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. 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. Administrative and support access should be purpose-bound and auditable. Application logs are designed to avoid bearer tokens and request arguments, but 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. SyncStaff can revoke project credentials, isolate a tenant, disable optional model calls, and preserve audit evidence while an incident is investigated.
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 September 9, 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.