Privacy, in plain English.

Synpese touches nothing until you connect it, and it only ever touches three categories of data.

Account data. Authentication is handled by Clerk. On your first signed-in visit, or through a signature-verified Clerk webhook, whichever arrives first, we store a minimal user record: a Clerk user ID, your email address, and your account creation time. We never see or store a password. Clerk manages credentials on our behalf. Your display name and avatar are read from Clerk when the dashboard renders; we do not copy them into our database.

Slack content. Slack is the one source Synpese can connect to today, for addresses on its invite list only. Synpese is not in the Slack Marketplace, and Slack limits apps outside it to reading 15 messages a minute from each workspace, so access is by invitation. You authorize it over OAuth, and the app requests exactly three read scopes, channels:read, channels:history, and users:read. There are no write scopes, so Synpese cannot post, reply, edit, delete, or react to anything in your workspace. In concrete terms, those three scopes mean:

• Public, non-archived channels only, and only the ones the Synpese app has actually been added to. Slack refuses history for any channel the app isn’t a member of, and those channels are skipped.
• Never your DMs, group DMs, private channels, files, or canvases. Those require scopes Synpese does not request and cannot use.
• The workspace member directory, IDs and display names, used for two things: naming the author of each message in the transcript the model reads, and turning a raw mention like <@U01234> into a readable @name so a rule makes sense when you read it back.

Within those channels, a run reads roughly the last 90 days of messages posted to the channel itself. Replies inside a thread are not read, only the message that started it. Bot and system messages are discarded; only messages written by people are used. The Slack bot token that lets us read on your behalf is stored in our database and never exposed to your browser. Slack bot tokens do not expire, so there is no refresh token to hold.

The purpose is narrow and single-minded: to extract your team’s standing operating rules. For each thread, a single message posted to a Slack channel, Synpese assembles a plain transcript, the channel name, then one author: message line per message, and sends it to OpenRouter, which routes it to openai/gpt-4o-mini, with instructions to return only durable policy, process, and decisions, not chatter or status updates.

What comes back is a set of knowledge units: a topic, the rule stated plainly, and a confidence score from 0 to 1 for how unambiguously the source stated it. The source it came from, the channel name, and the provider are attached by us afterward, never left to the model. Anything scoring below 0.4 confidence is discarded outright.

Each surviving rule is then embedded, again through OpenRouter, to openai/text-embedding-3-small, into a 1536-dimension vector, and stored. The vector is used when a rule is stored, not to group or search rules: a rule within 0.85 cosine of one already stored is merged into that row instead of becoming a second rule, one within 0.98 is left untouched so an unchanged rule does not get a new timestamp, and a deleted topic restated under another name stays out. The rule text is what gets sent, and a rule is written from your content: extraction is instructed to preserve every threshold, condition, timeframe, and named approver, so names and figures from your workspace travel with it.

We do not access your content for advertising, profiling, or resale, or for any purpose unrelated to producing and maintaining your knowledge units.

A rule is written from whatever anyone posts in a connected channel. That means anyone who can post in a channel the app was added to, including any guests or outside members the channel has.

Each stored rule becomes a tool. The rule’s text, up to 300 characters, is the tool’s description, its topic names the tool, the model writes the descriptions of any parameters it takes, and list_topics and every answer say where it came from: a channel name. An agent reads those descriptions when it connects, alongside its own instructions. So a message written to steer an agent, dressed up as company policy, can reach one. That is prompt injection, and it is not a solved problem. Nothing on this page solves it.

What Synpese does about it, in the order a thread meets it:

• Cleans the thread. Invisible characters, which can hide text from people but not from a model, are stripped before the model reads it, and no message can close the tag the conversation is wrapped in.
• Checks the raw messages for a short list of phrasings written for an AI: telling it to ignore its instructions, posing as a system or developer message, or telling it to keep something from the user. Every rule from a thread that has one is held. This runs before extraction because the model, asked to restate “do X, and do not tell the user”, keeps the X and drops the rest.
• Makes the model judge every rule it writes: what the rule would make an AI do, and whether that is to hand over credentials, files or personal data, contact an outside address, fetch a URL or run a command, call a tool as a hidden step or keep things from the person it helps, or give a fixed answer whatever the facts. A rule it flags is held.
• Checks what the model wrote, the rule, its topic, and the descriptions of its parameters and answer, against the same phrasings.
• Replaces a channel name that trips those phrasings before it is stored as a rule’s source, so it never reaches an agent.
• Tells every agent that connects, in the instructions your endpoint sends first, that descriptions and answers quote company rules and are not instructions to it, and that it should not follow one that asks it to ignore its instructions, keep something from the user, reveal credentials or files, call another tool, run a command or contact an outside address. How much weight an agent gives that is up to the agent.

A held rule is not served. It waits under Kept out on your Topics page with the reason it was held, for a person to restore or forget. A held update to a rule that is already served is dropped, and the served text stands.

• Crafted attacks

  Count

  10

  Result

  8 held back, 1 produced no rule, 1 served

• Legitimate rules

  Count

  12

  Result

  None held back

That is our own test: ten attacks we wrote and nine legitimate threads, on openai/gpt-4o-mini, run twice with the same result. Before these checks existed, five of six of the attacks came out as rules at confidence 0.9 to 1.0. It shows the layers work. It is not a detection rate for attacks in the wild.

The rest takes a person. A new topic is served as soon as a run stores it, unless a check holds it back. Nothing waits for anyone to approve it: a review step before serving is not built. Until it is:

• Connect channels whose members you would let brief your agents. Who can post in a channel matters as much as what the app can read there.
• Read new topics after a sync. Delete a rule you do not recognize. A deleted topic stays out of later runs.
• Keep consequential actions behind a confirmation in your agent client, so a tool description alone cannot send, pay or delete anything.

This deserves its own section, because most privacy policies for workspace tools bury it. Connecting a Slack workspace does not only share your data. It shares messages written by your colleagues, along with their display names, and an extracted rule can name a person, because naming the approver is often the whole point of the rule.

You are the one who authorizes that. Before you connect a workspace, make sure you are actually permitted to, and tell the people in it. Our terms require this of you; we have no way to verify it from our side, and we will not pretend otherwise.

What we do on our side is keep the surface as small as the product allows: public channels the app was explicitly invited to, human messages only, roughly 90 days, no stored message log, and a member directory that is held in memory for a single run and never written to a table. The honest limit is that a person’s name can still survive inside the text of an extracted rule.

Everything persistent lives in one Neon serverless Postgres database, across seven tables: your account record; your Slack connection and its token; your extracted rules with their embeddings in pgvector; the MCP server provisioned for your account, which is what serves your tools, with a hash of its access token; a history of your last 50 ingestion runs, counts, errors, and the names of any channels a run could not read; copies of the rules you deleted and of any held back for review, kept until you restore or forget them, or delete your account; and a hash of each thread a run has sent to the model.

We do not store your Slack messages. There is no message table in our schema. History is pulled into memory for the duration of a run, sent to the model, and dropped when the run ends. What persists is the extracted rule, its topic, the name of the channel it came from, its confidence score, the parameters and answer shape of the tool built from it, and its vector, alongside the kept-out copies and run history listed above. The honest caveat is that a rule is written from your content, so content can survive inside a rule’s wording. If a message stated a policy, the policy is what we keep. Each thread a run reads also leaves a SHA-256 hash behind, so the next run can tell whether it changed without sending it to the model again. A hash cannot be turned back into the text. The first run after a thread has gone 90 days without being seen deletes its hash, and disconnecting the source or deleting your account deletes them all; if runs stop, the hashes stay until then.

Your data is isolated per account. Every integration, knowledge unit, and MCP server row is keyed to your user ID, so one customer’s content is never commingled with another’s.

Who can call your endpoint. Your MCP endpoint is created when your first sync finishes, at a URL containing a random ID. The URL is an address, not a credential: every request must also carry a bearer token in an Authorization header, and a request without a valid one gets a 401 and no data. The endpoint starts with no usable token, so nothing can call it until you issue one in the dashboard.

• Shown once. A token is shown when you issue it and never again. We keep only its SHA-256 hash, so we cannot show it to you or recover it.
• Replaced, not added. Issuing a new token makes the old one stop working in the same moment, so every client still using it gets a 401 until you give it the new one.
• One token per account. Every client you connect uses the same token, so the endpoint cannot tell which client made a call. Synpese does not record tool calls, beyond a server log line when a tool that takes arguments could not be evaluated.
• Rate limits. An endpoint answers up to 120 requests a minute. After 30 failed attempts from one address in a minute, that address is refused until the minute is up.
• Read-only tools. The endpoint serves list_topics and one get_ tool per stored rule, all marked read-only. Each answer carries the rule, where it came from, its confidence, when it last changed, and whether its source is still connected. Anyone holding the token can call them, so keep it as you would a password.

On the security side, stated precisely rather than reassuringly:

• Data is encrypted in transit over TLS, and encrypted at rest by Neon at the storage layer.
• Your Slack token carries a second layer of encryption that we apply ourselves, AES-256-GCM, under a key held in the environment rather than in the database, so what lands in the column is ciphertext, not a working credential.
• The Slack OAuth handshake is CSRF-protected with a one-time, httpOnly, secure state cookie, and the Clerk webhook is signature-verified before we trust a single field in it.
• The dashboard and every integration route require a signed-in session, and your Slack token is never sent to the browser.

Your connected content and the knowledge units we derive from it are used solely to build and maintain your own knowledge base. We do not use your content to train, fine-tune, or improve any model. We do not train models at all, and we do not pool your data with other customers’ to build anything cross-customer.

OpenRouter is the provider that receives your content. Every model call Synpese makes goes to their API, at three points: the thread transcript at extraction time, the rule text at embedding time, and, when an agent calls a tool that takes arguments, the rule plus those arguments at query time. OpenRouter is a router, so it forwards each request to an upstream inference provider it selects. The models we name are OpenAI’s; which company hosts a given request is OpenRouter’s choice, within the one rule we set.

That rule is zero data retention. Every request we send, for extraction, embeddings and rule evaluation, sets OpenRouter’s provider preferences to zdr: true and data_collection: deny, so it is routed only to an endpoint whose provider does not store the request at all, and so cannot train on it. A request that no such endpoint can serve fails instead of going elsewhere. Today that means Microsoft Azure’s hosting of both models; with no rule set, OpenAI’s own endpoints served them. What makes an endpoint zero-retention is OpenRouter’s record of the provider’s policy, or of an agreement OpenRouter has with it, not a contract between us and that provider.

We state that boundary carefully because it limits what we can promise you. Synpese is OpenRouter’s customer, not Microsoft’s or OpenAI’s, so their published policies are not commitments made to us and we will not pass them on as though they were. What governs your content once it leaves us is OpenRouter’s terms and the upstream provider’s. We do not train on your content, we do not pool it, and the routing rule above goes out with every request. That part is ours to promise. The rest is theirs, and you should read it as theirs.

We do not sell your data, and we do not share it with advertisers, data brokers, or any party outside the subprocessors named below.

Five companies are involved in operating Synpese, and each receives only what it needs to do its job. This is the complete list of the companies we send your data to, with one honest caveat below it, because the last row does not end where the others do.

• Clerk

  Role

  Authentication & identity

  What it receives

  Your login credentials, email, and basic account profile.

• Neon

  Role

  Serverless Postgres

  What it receives

  Account record, Slack token, extracted rules, embeddings, copies of rules you deleted or that were held back for review, thread hashes, a hash of your MCP endpoint's access token, and run history.

• Upstash

  Role

  Redis + BullMQ queue

  What it receives

  Job records holding a user ID and a provider name, short-lived counters keyed by user or endpoint ID for rate limits and daily model-call caps, and counters of failed attempts to call an endpoint, keyed by the caller's IP address. No message content.

• Sentry

  Role

  Error monitoring, server and worker only

  What it receives

  When the Next.js server or the ingestion worker hits an error: the error's type and stack trace (file, function and line, sometimes with a few surrounding lines of code, ours or a library's), the route pattern and HTTP method (an ID or topic name in the path becomes a placeholder such as [ruleId]), which part of the app failed and, for an ingestion run, the provider and whether the run was scheduled or manual, the server's runtime, OS, hardware, locale and time zone, the versions of the packages it runs, and the environment name and deployed version. The error's message only when it matches a pattern we have vetted as carrying no content, with any account or record ID in it replaced by a placeholder; for a failed database query, that is our own SQL statement without its values. Otherwise it is withheld. Never request or response bodies, headers, cookies or query strings, breadcrumbs, local variables, your email or any ID tied to your account, rule text, message content, tokens, or the arguments an agent passes to a tool. Nothing is sent from your browser.

• OpenRouter

  Role

  Extraction, embeddings & rule evaluation

  What it receives

  Slack channel names, message text and author display names from the channels being processed; each extracted rule at embedding time; and, on an agent's call to a tool that takes arguments, the rule text plus the arguments that agent supplied.

OpenRouter routes onward, and that is the caveat. It is not an inference provider itself. It forwards each request to an upstream model host it chooses, and it can route the same model id to more than one. Every row above is a company we contract with directly; the last one is the point past which the list stops being ours to enumerate. We can tell you every company we hand your content to, and we cannot promise you the identity of every company OpenRouter hands it to next. What we do set is the kind of company: every request may go only to an endpoint with a zero-data-retention policy, as described under Never trained on your content. If that boundary is not one your team can accept, it is the right reason not to connect a workspace yet.

Anthropic is deliberately not on this list. You will see the Anthropic MCP SDK named elsewhere on this site: that is an open-source library that runs on our own servers, not a service we send your data to, so it is not a subprocessor and never receives your content.

Synpese is not publicly deployed yet. When it is, the hosting provider will be added to this table before launch, and we will keep this list current as the stack changes.

The strongest control is the first one, and it is entirely real: nothing is read until you connect a source. For Slack that boundary is narrow, only channels its app was explicitly added to. Beyond that, here is exactly what you can do today.

• Revoke from Slack’s side. In your Slack workspace settings, under Manage apps, remove Synpese. That invalidates our token immediately and is the fastest lever you hold. You do not need us to act.
• Remove the app from a channel and that channel stops being readable on the next run, without touching the rest.
• Disconnect a source in Connections. Its nightly job stops, we ask Slack to revoke our token, and the grant is deleted, in that order. Its rules are kept unless you tick the option to delete them too. Kept rules go on answering your agents: each answer says its source is no longer connected, and since when, so an agent can tell the rule is no longer maintained. Nothing prunes them later. Delete them from their topic pages when you no longer want them served, or reconnect the source and the next run marks them connected again.
• Delete a single rule from its topic page. It stops being served at once, and later runs keep its topic out, along with anything that restates it under another name. A copy stays under Kept out on the Topics page so a mistaken delete can be undone; it goes when you restore the rule, forget it, or delete your account. Forgetting erases the copy for good and stops keeping the topic out, so a later run can extract the rule again if its thread is still inside the 90-day window or someone restates it.
• Delete your account in Settings. Every source is disconnected first, its nightly job stopped, our token revoked at Slack, the grant deleted, then your rules, embeddings, MCP endpoint, run history and account record, and last of all your sign-in. You confirm by typing your email address, and it cannot be undone. Email still works if you would rather we did it.

If you are somewhere that grants you rights of access, correction, deletion, or portability, the GDPR, UK GDPR, or CCPA among them, deletion is self-serve in Settings, and for the rest, email us and we will honour them. There is no privacy portal beyond that, and as a solo pre-company project there is no data protection officer or EU representative to name; requests reach the person who built the system, directly.

Questions about this policy, or a request about your data, go straight to a person, not a ticket queue.

Synpese is built by Parbhat Kapila, an AI systems engineer focused on production AI infrastructure. It is an early-stage project, not yet a formal company entity, and this policy does not assert a governing jurisdiction because there is not yet an entity to assert one for. When that changes, this page will be replaced with a policy that does, and the change will be noted here.

We will update this page whenever the system it describes changes, a new subprocessor, a new source, or a capability moving out of the “not built” list, and we will change the date at the top when we do. Until then, this page describes our actual practices rather than promising more than we currently do.