> ## Documentation Index
> Fetch the complete documentation index at: https://docs.synheart.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Security overview

> What Synapse stores, where it runs, how it is encrypted, who can see what, and how data is deleted

This page is for the security reviewer at a team evaluating Synapse. Every statement on it was checked against Synapse's production code and infrastructure in November 2026. What applies to every Synheart product, including compliance, on-device processing and how to report a vulnerability, is on [Security at Synheart](https://docs.synheart.ai/security/overview.md). It covers what Synapse collects, where the data lives, how it is protected, who can see it, and how to delete it. Sub-processors are listed on [Sub-processors](https://docs.synheart.ai/synapse/subprocessors.md). A data processing agreement outline is on [DPA outline](https://docs.synheart.ai/synapse/dpa.md).

## At a glance

| Question | Answer |
| - | - |
| Where is data hosted? | Amazon Web Services, region **us-east-1** (N. Virginia, USA). For customers in the EU, UK or Switzerland, the DPA includes the EU Standard Contractual Clauses and the UK Addendum. |
| Is data encrypted at rest? | Yes. The database is encrypted with AWS KMS. Stored connector tokens and API keys also get an extra application-level layer (AES-256-GCM), with keys wrapped by a Synheart-managed AWS KMS key that rotates yearly. |
| Is data encrypted in transit? | Yes. TLS 1.2 or later on every public endpoint, between services, and to the database. |
| Does Synapse store source code, message text or email? | Not by default. Text is indexed only from sources an admin designates. Email, DMs, private channels, personal drives and source code are never indexed. |
| Does Synapse send our data to an LLM? | Only if explanations are turned on for your organization. They are off by default, and Synheart turns them on only when your organization asks. Then recommendation text and aggregate figures are sent to one model provider to write a short explanation, without names or organization memory. Search and Ask don't use a language model. Text is also sent to one embedding provider to build the search index (see [Sub-processors](https://docs.synheart.ai/synapse/subprocessors.md)). |
| Can a manager see one person's wellbeing data? | No. Human-state data is opt-in per person and shown only as team aggregates above the organization's cohort floor (default 10 people, never below 4). A smaller team sees its own view only if every member opts in. Agents receive delivery hints, never scores. |
| Does Synapse keep our agents' prompts? | No. When Synapse advises a coding agent, it keeps a decision record of identifiers only: the mode, reason codes and evidence ids. Never the prompt, question, code or diff. |
| Is there an audit log? | Yes. Admin and data actions are recorded and admins can read them. |
| Can we delete everything? | Yes. The organization owner can erase all of the organization's Synapse data, even without a Synapse seat or an active subscription. Every member can erase their own data, with or without a seat. |
| Compliance | **SOC 2 Type II** audit under way. Third-party penetration test completed; a summary is available on request. Not intended for protected health information (PHI). |

## 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.

These are never indexed, under any setting: **email bodies, direct messages, private channels, personal drives and source code.**

| Source | What Synapse keeps | What it never keeps |
| - | - | - |
| GitHub / GitLab | Commit SHA, author login, time and short subject line; pull/merge request number, author and lifecycle times. For designated repositories, the Markdown files (docs, RFCs, ADRs). | Code, diffs, full commit messages, author email, PR/MR descriptions, review comment text |
| Slack | Message and channel IDs, author and time. For designated public channels, message text from the last 90 days. | DMs, private channels, Slack Connect channels, attachments |
| Notion | For pages a member has shared with Synapse, the page title, URL and text. | Comments, media |
| Google Drive | For designated shared drives, document text, read through each member's own access. | Personal "My Drive" content |
| Linear | Issue key and title, state, team, owner and lifecycle times. History rows hold the actor's email, used only to match people across tools. | Descriptions, comments, attachments |
| Jira | Issue key and summary, status, assignee, project and times. | Descriptions, comments, worklogs, attachments |
| Google Calendar | Event ID with start and end time only. | Titles, descriptions, attendees |
| Microsoft 365 (see note) | Calendar event times; IDs and send times of sent mail; Teams post IDs and times; a OneDrive file inventory. See [Microsoft 365](https://docs.synheart.ai/synapse/microsoft-365.md). | Email subjects, addresses and bodies; Teams message text; file contents (unless a folder is designated) |
| Zoom | Meeting ID, host and start/end time. | Topics, participants, chat, recordings, transcripts |
| AI vendors (Anthropic, OpenAI, Cursor, GitHub Copilot) | Daily usage and cost counters, seat counts, and per-person rows under an org-local pseudonym, so that seat use can be counted and a person's rows erased. | Prompts, conversations, files |
| Coding-agent rules (Synheart CLI) | Per member, per day, per rule and per coding agent: how many times an action was stopped, asked about or allowed. | The command, file path, prompt or repository |
| Agent decision records | For each recall and intent check, and each guard check when the developer opts in: the mode (for example *asked*, *blocked*), reason codes, evidence identifiers, a task id (an issue number or a keyed digest), the coding agent and the time. Developers' accept/reject verdicts, with a reason code. Each member sees only their own. | The prompt, question or instruction text, code, diffs, excerpts, branch names, session ids in clear, secrets and human state |
| Team-sharing consents | Only active opt-ins to "share my numbers with my team": who, which team, when, and the disclosure version acknowledged | Nothing after an opt-out: the row is deleted at once |
| Explanations (only if turned on) | The explanation text the model wrote, once it passes Synapse's checks (including that it names no member); which recommendation and figures it explains; the model used; daily token counts per organization; helpful/not-helpful feedback with a reason code. Coaching explanations are per member and need their opt-in. | Prompts or responses at Syni or the model provider; free-text feedback |
| MCP agents | Decisions an agent is asked to `remember` and notes it is asked to `store` (personal notes stay private to their author). Tool-call telemetry records the tool name and time, never content. | Prompts or conversations |

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.

**In transit**

* 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.

Each person's opt-ins and opt-outs of team sharing are recorded as a consent record, but are deliberately left out of the organization's audit log, so it can't show a manager who hasn't opted in.

The audit log is kept for 6 years. See [Retention and deletion](#retention-and-deletion).

### 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

| Data | How long it is kept |
| - | - |
| Slack knowledge text | Last 90 days of each designated channel. Older messages are removed on the next sync. |
| AI seat observations | 90 days |
| Agent rule counts | 90 days, deleted daily |
| Agent decision records and accept/reject verdicts | 90 days, deleted daily |
| Explanations and their feedback | 90 days, deleted daily. A member's coaching explanations are deleted at once when they withdraw consent |
| Team-sharing consents | Only while active. Deleted as soon as the person opts out or their team changes |
| Team-sharing consent records (who opted in or out, and when) | Kept as proof of consent while the consent is active and for 6 years after it ends, deleted daily |
| Items deleted in the source tool | Removed on the next sync |
| Audit log | 6 years, deleted daily |
| Tool-call activity (which Synapse tool was called, by whom, when) and meeting times | 630 days, deleted daily |
| Organization memory and other activity data | Until removed through one of the controls below, or until the organization is erased |
| Database backups | Up to 35 days after deletion from the live database |

**Deletion controls**

| Control | Who | What it deletes |
| - | - | - |
| Revoke a knowledge source | Admin | The source's indexed text, right away |
| Disconnect a tool with **purge** | Admin | Everything Synapse ingested from that tool. Disconnecting without purge keeps the data. |
| Forget (MCP `forget`) | The author | Their own notes and the organization documents they authored |
| Erase my data | Any member of the organization, with or without a seat, including after the subscription has lapsed | Their identities, personal notes, telemetry, AI-usage rows, agent rule counts, decision records and verdicts, team-sharing consent and Synheart Life link. Their name is removed from commit attribution and pseudonymized in the audit log and consent records. Shared organization memory stays. |
| Erase the organization | Organization owner only. No seat or active subscription is needed. The request must name the scope and the organization explicitly, and the owner types the organization's slug (or name) to confirm | All Synapse data for the organization, including decision records, team-sharing consents and privacy settings. Google access grants are revoked with Google and agent tokens are revoked. Audit rows are pseudonymized. Every erase is audited. |
| Opt out of team sharing | The person | Their team-sharing consent, at once. Their team's shared view is withheld from then on |
| Turn off team human-state views | Organization owner, organization admin or Synapse Admin | Hides all team human-state views immediately; deletes nothing |
| Disconnect Synheart Life | The person | Stops all use of their human state immediately |

## 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.

Report a security issue to **[security@synheart.ai](mailto:security@synheart.ai)** (see [Vulnerability disclosure](https://docs.synheart.ai/security/disclosure.md)). If a personal data breach affects your organization's data, Synheart notifies you without undue delay; the notice period is set in your DPA.

## 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.

## Ask us

Questions from your security team: **[security@synheart.ai](mailto:security@synheart.ai)**.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.