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.
These commitments flow from the four hard rules and govern Mavrick’s day-to-day operation.
- No model training on customer data.
Mavrick does not use customer data — message content, integration data, or workspace metadata — to train, fine-tune, or evaluate AI models. Not Mavrick's models, not third-party models.
- Encryption in transit and at rest.
All data in transit is encrypted with TLS 1.3. All data at rest is encrypted with AES-256. Vault credentials use pgsodium with isolated master key.
- Workspace data isolation.
Customer data is logically isolated per workspace via Postgres Row-Level Security policies. No cross-workspace data path exists in production code.
- 90-day rolling retention.
Slack messages persisted under Rule 2 are retained for 90 days rolling, then automatically purged.
- Workspace data export on request.
Workspace admins can request full data export at any time; delivered within 14 days as JSON archive.
- Workspace data deletion on request.
Workspace admins can trigger full data deletion via Slack slash command (/mavrick purge-workspace) or written request; completed within 7 days.
- Workspace uninstall purges message bodies.
Uninstalling Mavrick from a workspace triggers automatic purge of all message bodies persisted under Rule 2; metadata retained 30 days for billing reconciliation, then purged.
- Subprocessor notification.
Material changes to the subprocessor list are published on /trust with reasonable notice. Enterprise customers may request advance notification.
- Incident notification.
Customers affected by a P0 or P1 security incident are notified within 72 hours of confirmation, via primary workspace contact.
Honesty about limits is part of trust. The following are things this charter does not promise. Procurement teams asking these questions should plan accordingly.
This charter does not promise that no Mavrick employee or contractor ever has technical access to systems where customer data lives. Mavrick's engineering team has the access required to operate, debug, and maintain the platform. Access is logged and audited.
This charter does not promise on-premises hosting or customer-managed encryption keys. Mavrick is a cloud SaaS product. Customers requiring those controls should evaluate the Strike Group enterprise tier.
This charter does not promise zero data sharing with subprocessors. Mavrick uses subprocessors listed on /trust to operate. Customer data may pass through those subprocessors as required by the architecture.
This charter does not promise immunity from compelled disclosure. If Mavrick receives a legally-compelled request for customer data (subpoena, search warrant, court order), Mavrick will comply with the law. Where legally permitted, Mavrick will notify the affected customer before complying.
This charter does not promise the absence of human review during incident investigation. If a security incident requires human review of specific customer data to investigate, Mavrick reserves the right to perform that review under the documented Incident Response Plan.
This charter does not promise indefinite product availability. Like any SaaS, Mavrick may shut down, be acquired, or change business models. In any such event, customers will be given reasonable notice and the ability to export their data.
We list these explicitly because honesty about limits is part of trust. A privacy document that promises everything is promising nothing.
How this charter changes.
- 1.Revision triggers.
Material changes to this charter are triggered by: changes in applicable regulations, changes in subprocessor architecture that affect any of the four hard rules, customer-driven contractual requirements that require strengthened commitments, or material business model changes.
- 2.Revision review.
Proposed changes are reviewed against the existing four hard rules. A change that weakens any of the four hard rules requires a major version bump (e.g., v1.0 → v2.0) and 30 days' notice to existing customers. A change that strengthens or clarifies the rules requires a minor version bump (e.g., v1.0 → v1.1) and standard publication.
- 3.Revision publication.
Every revision is published with: a new version number, a new effective date, a one-paragraph change rationale, and a diff showing exactly what changed. Prior versions remain accessible in perpetuity at /privacy-charter/v[X.Y].
- 4.Customer notification.
Major version bumps trigger 30-day customer notification via primary workspace contact. Minor version bumps are published without separate notification but are reflected in the next monthly compliance review log.
- 5.Customer recourse.
If a customer materially disagrees with a major version change, they may continue operating under their signed-version terms for the remainder of their then-current contract term, after which the new version applies on renewal.
| Version | Effective date | Changes | |
|---|---|---|---|
| v1.0(current) | April 15, 2026 | Initial charter publication. | View in full → |
This document is version 1.0 of the Mavrick Privacy Charter, effective April 15, 2026. It is the source of truth for privacy commitments referenced on /product, /trust, and related pages. Version history and prior versions are available above. Questions or evidence requests: admin@getmavrick.com.