Security practices

Every model call, policy decision, and administrative action is recorded in an append-only audit trail with a hash chain, so a deleted or altered entry is detectable.

Records capture who, what, when, which model, which policy applied, and the outcome. Prompt and completion bodies are not stored in the audit trail; the trail records that a call happened and how it was governed.

Models available to a workspace are registered with their provider, region, and entitlement. AI use cases are registered with an owner, a risk classification, and the models bound to them.

A model that is not registered cannot be called. Use case registration is what makes the record-keeping obligations answerable without a manual survey.

Evaluation runs score model outputs against defined criteria and record the result against the model card.

The evaluation runner and model cards are in place. A standing bias evaluation suite with published methodology is a roadmap item, so this control is marked partial rather than implemented.

A strict content security policy is served on every application response. Inline script is blocked and styles are served from stylesheets rather than inline attributes.

The policy is nonce-based. It is enforced rather than report-only, and violations are reported to an internal collector.

Every change goes through pull request review, automated static analysis, dependency vulnerability scanning, secret scanning, and a security-focused review gate before it can reach production.

Static analysis and dependency scanning run on every pull request and block the merge on a high severity finding. Direct pushes to the release branch are not permitted.

Automated backups with point-in-time recovery. Backups are encrypted and retained according to the published schedule.

Restore procedures are documented. Recovery time and recovery point targets are published on the reliability page.

A periodic exercise that restores from backup into a clean environment and measures the result against the published recovery targets.

Backups exist and restore procedures are documented, but a full exercise has not been run. This is the most significant open gap on this page and it is published as a roadmap commitment with a target quarter rather than being described in softer terms.

Prompts are scanned for sensitive data classes before they leave the platform for a model provider. Detected content is redacted, blocked, or quarantined according to workspace policy.

The scan runs as a pre-gate, ahead of the provider call, so a blocked prompt is never transmitted. Detector coverage and thresholds are configurable per workspace and every decision is recorded in the audit trail.

Retention periods are set per data class and per workspace. Workspace deletion removes customer content within the published window.

Per-user deletion is available and is recorded in the audit trail. An explicit identity verification step on the per-user flow is a published roadmap item and is not yet in place, which is why this control is marked partial rather than implemented.

Workspace data can be exported in standard formats. The export covers conversations, memory graph facts, audit records, and configuration.

Export is self-serve on the Business tier. Exposing the same capability as a subject access request endpoint is a published roadmap item, so this control is marked partial.

A workspace can constrain which regions its data may be processed in. A model provider that cannot satisfy the constraint is not offered for that workspace rather than being silently substituted.

The routing decision is made before dispatch and is recorded with the call. A constraint that cannot be satisfied fails the call with an explicit reason instead of falling back.

All customer data at rest is encrypted with AES-256. Databases, object storage, backups, and log archives are covered.

Keys are managed by the cloud key management service. Workspace-scoped keys are available on the Enterprise tier for customers who require a per-workspace key boundary.

TLS 1.2 or higher on every external connection, with modern cipher suites only. Internal service-to-service traffic is encrypted on the same terms.

HTTP Strict Transport Security is set at the edge. Plain HTTP is redirected rather than served.

Application secrets and customer-supplied provider credentials are held in a managed secrets store, encrypted with a dedicated key, and are never written to source control or to logs.

Customer-supplied provider keys live under a per-workspace path so a grant cannot be written broadly enough to reach another workspace's credentials. Automated scanning blocks a commit that would introduce a credential.

Multi-factor authentication is available on every account and can be required at the workspace level by an administrator. Enrolment supports authenticator apps and hardware security keys.

Enrolment is bound to a short-lived server-issued cookie so a secret cannot be silently generated for a session that never completed the flow. Backup codes are single use and hashed at rest.

SAML and OIDC single sign-on with SCIM directory provisioning. Custom claims that carry workspace scope are read from the access token, not the identity token.

Identity is brokered so a customer can federate a multi-tenant corporate directory without us holding a per-customer connection secret.

Sessions use a sliding expiry and are bound to an opaque server-side identifier rather than a self-contained token, so a session can be revoked immediately rather than waiting for it to expire.

Session records live in a dedicated store. Revoking a session deletes the record; the cookie alone grants nothing.

Application, infrastructure, and access logs are centralised with defined retention. Alarms cover error rate, latency, authorisation failures, and cost anomalies.

Log groups have explicit retention rather than defaulting to indefinite. Alarms notify an on-call rotation.

Public surfaces sit behind a content delivery network with a web application firewall, managed rule groups, and rate-based rules. Origins are not directly reachable.

Rate limits are applied per endpoint class rather than globally, so an abusive caller on one path does not degrade another.

Access to production systems is granted on the principle of least privilege and is reviewed periodically. Access is removed on role change and on departure.

Production access requires multi-factor authentication and is recorded. A formalised quarterly review cadence with a signed record is pending, so this control is marked partial.

Physical security of the underlying data centres is provided by the cloud infrastructure provider under the shared responsibility model.

SynapBridge operates no data centre and holds no customer data on physical media. The provider's own third-party attestations cover this domain, and their reports are available directly from them.

Every table holding customer data carries row level security in FORCE mode, keyed on the workspace identifier. A query that does not bind a workspace returns zero rows rather than every row.

FORCE rather than ENABLE means the policy applies to the table owner as well. The database user the application connects as does not hold the bypass privilege, so a scoping bug in application code cannot read across workspaces.

Production, staging, and development run in separate cloud accounts with no shared credentials and no network path between them. Deployment to production requires a separate approval from deployment to any other environment.

Cross-account access is granted by resource policy for named roles and specific resources, never by a shared credential.

Sub-processors are assessed before onboarding and the register is published. Customers receive at least 30 days notice before a new sub-processor begins processing.

The register is the source of truth and the notice date is recorded per entry. A formalised annual reassessment cadence is pending, so this control is marked partial.

Dependencies are scanned continuously for known vulnerabilities. Container images are scanned before they can be deployed.

A high or critical finding blocks the merge. A software bill of materials published per release is a roadmap item.

Annual third-party penetration testing, plus a test on any major architecture change.

The first engagement has not yet run. This control is published as planned rather than implemented, and the summary letter will appear in the reports library when it exists. Internal security probes run continuously in the meantime.

A published disclosure policy with a stated scope, a safe harbour commitment, and response time commitments by severity. Reports go to security@synapbridge.com.

Acknowledgement within two business days, triage within five, and a remediation target of seven days for critical findings. A paid bounty programme is a roadmap item and is not claimed here, because a bounty that does not pay costs more credibility than it earns.