You are viewing version 1.0 of the Merit Privacy Charter (effective April 15, 2026). This is the current version. The canonical URL is /privacy-charter.
The Merit Privacy Charter
This charter is a contractual statement of how Merit handles the data you trust to it. It binds Merit to specific commitments, listed below. Where this charter conflicts with a less-restrictive statement elsewhere on the Merit site or in Merit’s terms of service, this charter governs.
This charter is versioned. Every material change is a numbered, dated revision with a published diff. Customers may at any time request the version of this charter that was in effect on the date they signed Merit’s terms.
This charter does not replace the Terms of Service, the Data Processing Agreement, or applicable regulations (GDPR, CCPA). It is in addition to those documents and operates alongside them. In case of conflict between those documents and this charter, the more-protective provision applies to the customer’s data.
The following four rules are contractual commitments. Merit will not weaken any of them without a numbered version revision, a published diff, and 30 days’ notice to existing customers.
Merit reads Slack channel history only when a user-triggered task is actively executing and reading that history is required to complete the task.
Merit does not run cron jobs that scan customer channels. Merit does not perform batch ingestion of channel content. Merit does not “read everything on install.”
In practice:When a user types @Mavrick what's our spend this week?, Merit may read recent thread context related to that question. When no user is actively asking Merit something, Merit is not reading.
Merit stores the body content of a Slack message only when Merit was a direct party to that message — meaning a user @mentioned Merit, DMed Merit, or Merit replied in the thread.
Ambient channel content — messages between users that did not involve Merit — is never persisted to Merit's database.
In practice:Merit can see a message in real-time when reading channel context to fulfill a task (per Rule 1), but that message is not stored unless Merit was a direct party.
Every action Merit takes that mutates data in a customer's connected account — pausing a campaign, sending an email, transferring budget, modifying a record — requires explicit user approval before execution.
Merit does not offer an “always approve” preference. Customers cannot disable the approval gate per-tool, per-workspace, or per-user.
In practice:A customer cannot accidentally configure Merit to take destructive action without confirmation. The approval gate is part of the architecture, not a user setting.
OAuth tokens for connected services are held by our managed connector layer (SOC 2 Type 2 certified). For direct credentials, Merit stores them in Supabase Vault using pgsodium with AES-256 encryption and an isolated master key.
The AI model that drives Merit's reasoning never receives raw credentials. The model sees descriptions of available tools and the workspace context required to invoke them. Credentials are injected at the tool-call boundary by the Tool Gateway, not in the prompt.
In practice:Even a successful prompt-injection attack against Merit cannot exfiltrate customer credentials, because the model never sees them.
This is version 1.0 of the Merit Privacy Charter, effective April 15, 2026. Return to current version →