At a glance
What Synapse stores
Synapse has two tiers of data for every connected tool:- Activity (default). Identifiers, authors and timestamps, used to build team-level views. No message or document text.
- Knowledge (opt-in). Text from containers an admin explicitly designates as knowledge sources, such as one repository, one public Slack channel or one shared drive. Knowledge text is indexed so agents can recall organization decisions. An admin can revoke a source, and its indexed text is deleted at once.
The Microsoft 365 connector is not available yet: it has no production credentials. Synapse stores nothing from Microsoft 365 until it is.
Human state (opt-in)
Synapse can adapt how coding agents respond to the engineer’s current focus, and show team-level trends. This data is handled differently from everything else:- Opt-in per person. It comes only from the person’s own Synheart Life app. It requires them to link Life, consent to workplace contribution, and consent to cloud processing. They can disconnect at any time, and Synapse stops using their data immediately.
- Stored in the person’s own space, not the employer’s. Synapse reads a short-lived snapshot (older than 2 hours is ignored). It does not copy scores into the organization’s data.
- Team aggregates only, above a floor. Every team figure needs at least the organization’s cohort floor of contributing people; below it the figure is withheld, not estimated. The floor is 10 by default and each organization can set it from 4 to 50. The organization owner, an organization admin or a Synapse Admin can change it. Lowering it requires acknowledging a disclosure, and every change is audited. Every member can see the current value. If the floor can’t be read, team views are withheld as if it were 50.
- Organizations can turn team human-state views off. They are on by default. The organization owner, an organization admin or a Synapse Admin can turn them off. This immediately hides every team and department human-state value: on the dashboard, in exports, digests and alerts, and in the team tools an AI assistant can call. Work-only metrics and each person’s own view stay. Turning them back on requires acknowledging the disclosure again. The setting can only hide data; it never releases anything a person hasn’t consented to.
- Consent-based sharing below the floor. A team smaller than the floor gets a team view only while every current member has opted in to “share my numbers with my team”. It works like this:
- Nobody can opt anyone else in, including managers, admins and owners.
- Opting out is one click, takes effect immediately, and works without a seat.
- A new member withholds the view until they opt in.
- Members of the team see which teammates opted in. Everyone else sees only “shared” or “not shared”, never names or a count.
- The organization owner, an organization admin or a Synapse Admin can turn the feature off for the organization. That withholds every shared view at once and keeps people’s choices.
- Figures already sent in an export, webhook, digest or alert can’t be recalled.
- Explanations can include team averages. If explanations are turned on, the figures sent to the model provider can include team or department averages of human-state measures, only those that already passed the cohort floor. These are the same aggregates the dashboard shows: never one person’s state, a raw signal or a reading. Coaching tips use only the member’s own meeting and focus shares, not human state.
- Agents never see scores. An agent receives only delivery guidance, such as “be concise” or “suggest an extra review”. It never receives a score, a band or a raw signal.
- No individual view. Synapse has no per-person human-state view, ranking or manager drill-down. On the Synaptic Mesh, a person’s human state appears only on their own nodes, for every role. Decision records hold no human state.
Where data is hosted
- Cloud: Amazon Web Services, us-east-1. The API, the dashboard and the database all run there, on a Kubernetes cluster (Amazon EKS) in private subnets with no public IPs.
- Database: Amazon Aurora PostgreSQL across two availability zones, not publicly reachable.
- Backups: automated database backups with point-in-time recovery, kept for 35 days. Deletion protection is on.
Encryption
At rest- The Synapse database is encrypted with AWS KMS. Today it uses the AWS-managed RDS key, not a customer-managed key.
- OAuth tokens and API keys for connected tools (GitHub, Slack, Notion, Google, Linear, Jira, AI vendors) and export webhook secrets are also encrypted in the application with AES-256-GCM. The data keys are wrapped by an AWS KMS key that Synheart manages (an AWS customer-managed key) with automatic yearly rotation. The key is shared by several Synheart services, but IAM lets each service unwrap only its own keys (enforced through the KMS encryption context), so only the Synapse service can unwrap Synapse’s. Every unwrap is logged in AWS CloudTrail.
- Kubernetes secrets are envelope-encrypted with a customer-managed KMS key. Node disks and S3 buckets are encrypted.
- Public endpoints (
api.synheart.ai,synapse.synheart.ai) accept TLS 1.2 or later only. The dashboard sends HSTS. - Traffic from the API gateway to the cluster is HTTPS.
- Service-to-service gRPC calls must use TLS in production. A service configured without it refuses to start.
- The database rejects connections that aren’t TLS (
rds.force_ssl=1, minimum TLS 1.2).
Access control
Customer access
- Sign-in goes through Synheart accounts: Google, GitHub or Apple, or your organization’s Google sign-in found from your work email. MFA is supported.
- Roles. Organization owners and admins manage the organization, its billing and its Synapse seats. Inside Synapse, what a person can do comes from their seat’s role: Admin, Lead or Member. Without an active seat, nobody has Synapse product access, the owner included.
- Members use organization memory, connect their own accounts, and see their own views, their own decision records and their own department’s team view. In an organization with no departments, the whole organization is their team.
- Leads also see organization-wide team views and can export them.
- Admins have everything Leads have, and also connect and disconnect tools, designate knowledge sources, manage departments, restrict documents and read the audit log.
- Privacy settings (the cohort floor, team human-state views and the team-sharing switch) can be changed by the organization owner or an organization admin without a seat, or by a Synapse Admin. Changing a setting grants no access to the data it governs.
- Erasure. Only the organization owner can erase the whole organization; it needs no seat and no active subscription. Every member can erase their own data, seat or not.
- Source permissions carry through. A Notion page or Drive document is only returned to members who can see it in the source tool. Documents an admin marks restricted are visible only to their author and admins. A document whose audience can’t be resolved is withheld.
- Agent tokens. MCP tokens are scoped per tool (for example
mcp:recall,mcp:remember,mcp:forget) and can never exceed the permissions of the person who created them. Access tokens last an hour. A replayed refresh token revokes the whole credential. Organization service tokens can never read human state. - Rate limits apply per caller on MCP, search and sync endpoints.
- Single sign-on. Organization sign-in works with Google today. Microsoft sign-in is built but not yet available. SAML single sign-on and SCIM provisioning are not available.
Audit log
Admins can read the organization’s audit log in Synapse. It records who did what and when, never content. It covers:- connecting, changing and disconnecting tools (including purges);
- designating and revoking knowledge sources;
- issuing and revoking MCP tokens;
- forgetting and restricting documents;
- linking and unlinking identities and Synheart Life;
- department, goal and alert changes;
- privacy setting changes (the cohort floor, team human-state views and the team-sharing switch), with the old and new value;
- exports and export webhooks;
- erasure.
Synheart staff access
- Synheart’s internal admin tools are reachable only over a private network (VPN). They are not exposed to the internet.
- Admin actions taken through Synheart’s internal admin service are recorded in an append-only audit log, with the admin’s identity taken from their sign-in.
- Production infrastructure changes are recorded in AWS CloudTrail. Sensitive changes (IAM, KMS, databases, the Kubernetes cluster) raise real-time alerts to the engineering team.
- AWS GuardDuty threat detection runs on the production account, and AWS Security Hub tracks the CIS and AWS Foundational Security Best Practices benchmarks.
Network protection
- The dashboard (
synapse.synheart.ai) is behind AWS WAF, with AWS managed rules (common exploits, known bad inputs, SQL injection, IP reputation) and per-IP rate limits. - The API (
api.synheart.ai) is behind AWS WAF too. - Application services run in private subnets. The Kubernetes control plane has no public endpoint.
Retention and deletion
Deletion controls
Monitoring and incident response
- Production logs, metrics and alerts run on infrastructure Synheart hosts itself in the same AWS account.
- AWS CloudTrail (all regions, log file validation on, KMS-encrypted) is kept for 365 days. VPC flow logs are kept for 365 days.
- Application logs are kept for 7 days.
Compliance
- SOC 2 Type II: Synheart is undergoing its SOC 2 Type II audit. 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: Synapse is not intended for protected health information (PHI), and Synheart does not sign business associate agreements today. Ask us before sending PHI.