Skip to main content
This page covers what applies to every Synheart product: Synheart Platform and its SDKs, Synheart Life and Synapse. Each product has its own page for what it stores. For Synapse, see the Synapse security overview.

Privacy by design: on the device first

Much of what Synheart does never needs the cloud.
  • Human state is computed on the device. The Synheart runtime turns wearable and phone signals into human-state estimates on the person’s own device. See Synheart Core.
  • Only derived data leaves the device, and only with consent. When cloud upload is turned on, the runtime sends derived human-state snapshots (HSI). Raw biosignals, notification text and clipboard contents are never uploaded. See Cloud protocol.
  • Three consent gates. A sensitive feature runs only when Synheart allows it for the product, the app’s policy allows it, and the person has granted that specific consent. Consent can be withdrawn at any time, and the runtime stops within its next cycle. See Consent system.
  • Every upload is signed and carries consent. Uploads are signed by the device and carry a consent token from Synheart’s consent service. The cloud rejects an upload that lacks either.
  • Behavior signals stay local. The Synheart Behavior SDK makes no network calls of its own. Identifiers are hashed before anything leaves the device. See the Behavior threat model.
  • Coding-agent rules run locally. The Synheart CLI checks agent actions against your rules on the developer’s machine. Synapse receives only counts, never the command, file path or prompt.

In the cloud

Synheart’s cloud services (Platform, sign-in, consent, billing and Synapse) run on one hardened infrastructure.
  • Hosting. Amazon Web Services, region us-east-1 (USA). Services run on Amazon EKS in private subnets with no public IPs, and the Kubernetes control plane has no public endpoint.
  • Databases. Amazon Aurora PostgreSQL across two availability zones. They are not publicly reachable and are encrypted at rest with AWS KMS. Automated backups support point-in-time recovery, and deletion protection is on.
  • Secrets and tokens. Stored credentials, such as connector tokens and API keys, are also encrypted in the application with AES-256-GCM. The keys are wrapped by a Synheart-managed AWS KMS key that rotates yearly, and each service can unwrap only its own.
  • Encryption in transit. TLS 1.2 or later on public endpoints, between services and to the database.
  • Web protection. Synheart’s web apps (synheart.ai, the Platform portal, sign-in, the Synapse dashboard and the Synheart API at api.synheart.ai) sit behind AWS WAF, with AWS managed rules and per-IP rate limits.
  • Sign-in. Synheart accounts sign in with Google, GitHub or Apple. MFA is supported.
  • Monitoring. AWS CloudTrail covers every region, with log file validation, and is kept for 365 days. Sensitive infrastructure changes raise real-time alerts. AWS GuardDuty threat detection runs on the production account, and AWS Security Hub tracks the CIS and AWS Foundational Security Best Practices benchmarks.
  • Staff access. Synheart’s internal admin tools are reachable only over a private network. Admin actions are recorded in an append-only audit log.

Compliance

  • SOC 2 Type II: Synheart is undergoing its SOC 2 Type II audit, covering its cloud services. Ask us for the report once it is issued.
  • Penetration testing: an independent third party has tested Synheart. A summary of the results is available on request.
  • HIPAA: Synheart products are not intended for protected health information (PHI), and Synheart does not sign business associate agreements today.

Report a vulnerability

Email security@synheart.ai. See Vulnerability disclosure for what to include and what to expect from us. If a personal data breach affects your organization’s data, Synheart notifies you without undue delay.