You are viewing version 1.0 of the Mavrick Privacy Charter (effective April 15, 2026). This is the current version. The canonical URL is /privacy-charter.
The Mavrick Privacy Charter
This charter is a contractual statement of how Mavrick handles the data you trust to it. It binds Mavrick to specific commitments, listed below. Where this charter conflicts with a less-restrictive statement elsewhere on the Mavrick site or in Mavrick’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 Mavrick’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. Mavrick will not weaken any of them without a numbered version revision, a published diff, and 30 days’ notice to existing customers.
Mavrick reads Slack channel history only when a user-triggered task is actively executing and reading that history is required to complete the task.
Mavrick does not run cron jobs that scan customer channels. Mavrick does not perform batch ingestion of channel content. Mavrick does not “read everything on install.”
In practice:When a user types @Mavrick what's our spend this week?, Mavrick may read recent thread context related to that question. When no user is actively asking Mavrick something, Mavrick is not reading.
Mavrick stores the body content of a Slack message only when Mavrick was a direct party to that message — meaning a user @mentioned Mavrick, DMed Mavrick, or Mavrick replied in the thread.
Ambient channel content — messages between users that did not involve Mavrick — is never persisted to Mavrick's database.
In practice:Mavrick 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 Mavrick was a direct party.
Every action Mavrick 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.
Mavrick 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 Mavrick 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, Mavrick stores them in Supabase Vault using pgsodium with AES-256 encryption and an isolated master key.
The AI model that drives Mavrick'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 Mavrick cannot exfiltrate customer credentials, because the model never sees them.
This is version 1.0 of the Mavrick Privacy Charter, effective April 15, 2026. Return to current version →