Scope
Hosted Synapsor Cloud services, public domains, control panel, gateway, authentication, tenant isolation, billing, backup/restore, and published SDKs.
Security
Security disclosure.
Report suspected vulnerabilities in Synapsor Cloud, hosted control-plane APIs, authentication, tenant isolation, billing, backup/restore, or deployment infrastructure to security@synapsor.ai during controlled beta.
Security reports are operator-reviewed during controlled beta. Free access still requires invite approval, and response times remain best-effort unless separately agreed in writing.
Out of scope
Denial-of-service testing, social engineering, physical attacks, destructive tests, and tests against third-party services outside Synapsor control.
Expectations
Use good-faith testing, avoid data access beyond proof of impact, preserve tenant privacy, and include reproducible details.
External database boundary
Agents propose. Synapsor records. Your runner writes.
Synapsor is designed so existing Postgres/MySQL applications can keep their database as source of truth while agent changes move through evidence, approval, replay, and conflict-checked writeback.
No model database credentials
The model never receives your Postgres/MySQL connection string, raw SQL access, or write credential. Agent-facing tools call approved Synapsor capabilities with trusted session values.
Read-only external mappings first
External sources are connected with least-privilege read credentials, selected tables/views, allowed fields, tenant scope, row limits, timeouts, evidence capture, and query audit.
Review branch in Synapsor
A risky external-database change becomes a write proposal plus Synapsor review-branch state: row diff, evidence, approval status, replay record, and writeback intent. The external database is not physically branched.
Trusted runner applies approved writes
Your backend environment runs the trusted runner with separate write credentials. It applies only approved proposals with tenant, primary-key, allowed-column, conflict, idempotency, and affected-row checks.
Database MCP boundary
Synapsor constrains the database state transition, not every MCP risk.
MCP standardizes how a client discovers and calls tools. Synapsor adds database-specific controls around what the model can request, what stays trusted, what becomes a proposal, and what the runner may commit.
text
MCP client
|
Synapsor Runner / MCP server
| \
| -> Synapsor Cloud: tools, proposals, approval, replay
|
Customer environment: DB credentials + guarded worker
|
Postgres/MySQLSynapsor protects
- model-facing raw SQL exposure in the Synapsor path
- trusted tenant, principal, source, and object scope
- proposal-before-write for risky database actions
- exact before/after diffs and evidence handles
- allowed-column, primary-key, tenant, conflict, and idempotency guards
- terminal applied/conflict/failed receipts and replay
Synapsor does not claim to protect
- malicious or compromised MCP hosts
- stolen local database credentials outside the runner
- unsafe non-Synapsor MCP tools
- prompt injection itself
- data already returned to a model
- OAuth, SSRF, or token mistakes outside Synapsor
- business invariants not represented in a capability or trusted app handler
Controlled-beta posture
Security commitments stay explicit.
These are the areas early teams usually ask about before connecting agent workflows. Items marked planned are roadmap posture, not certification or production guarantees.
Encryption
Hosted beta uses encrypted managed storage and encrypted secret material for operational credentials. Customer-managed keys and formal key-management commitments are planned, not yet generally available.
Tenant isolation
Control-plane APIs bind requests to approved accounts, projects, databases, API keys, and quotas. Synapsor also treats tenant/principal session values as trusted capability inputs instead of prompt text.
Backups and restore
Automated backup and restore verification are part of the controlled-beta operating path. Self-service destructive restore and customer-facing PITR remain operator-controlled.
Incident response
Incidents are handled by the founder/operator during controlled beta. Response times are not guaranteed unless separately agreed in writing.
Retention
Free and Builder backup-retention targets are documented in the plan limits. Broader retention, deletion, and export commitments need review before wider public launch.
Compliance roadmap
Synapsor does not currently claim SOC 2, HIPAA, GDPR certification, or other compliance attestation. Subprocessor and formal compliance documentation are planned for later review.