Trust, security, and compliance.

Mavrick’s compliance program clock started on April 15, 2026, with continuous internal logging from day one. Type 1 fieldwork with an external auditor is scheduled to begin in mid-2026. A six-month Type 2 observation period is planned to begin immediately following Type 1 issuance, running through Q2 2027.

While the Type 1 certificate is in progress, Mavrick operates to the same trust services criteria the audit measures. The Privacy Charter contractually binds us to those controls. Customers and prospective customers can request the current evidence folder under MNDA.

These are the four hard rules in the Mavrick Privacy Charter. They are contractual commitments, not posture statements. Every change to this list is a published, dated diff.

Policy statements are necessary but not sufficient. Below are the runtime protections that enforce those statements, with the implementation details a security reviewer can verify in our codebase.

• ⊢
  Cross-tenant isolation (IDOR defense). Workspace resolution on every API route is cookie-authoritative. A logged-in user who appends ?workspace_id=<other> to a URL or body receives 403 workspace_access_denied; the database query is not even issued. The resolver lives in one canonical helper (lib/auth/resolve_workspace_id.ts) so the policy is enforced uniformly, not per-route. Pen-tested May 2026; remediation completed same day.
• ⊢
  Webhook idempotency. Stripe events are written through a UNIQUE primary-key gate on processed_stripe_events before any dispatch runs. If Stripe retries a delivery (network jitter, dropped ACK), the duplicate is caught at the PG level (23505 unique_violation), returns 200 received:true with duplicate:true, and the side-effecting dispatch never fires twice.
• ⊢
  Per-IP rate limiting on public surfaces. Upstash Redis sliding-window limits applied to all unauthenticated public endpoints: /api/slack/events (200/min), /api/stripe/webhook (120/min), /api/pipedream/webhook (200/min), /api/meta-ads/callback (60/min), /api/tiktok-ads/callback (60/min). 429 responses include retry_after_seconds. Limiter fails open (allows traffic) when Redis is unreachable to avoid converting a cache outage into a full availability incident.
• ⊢
  Per-workspace concurrency caps. A sliding 90-second window enforces a maximum of 5 simultaneous agent runs per workspace (env-overridable). Cap-hit returns an honest customer-facing message ("Mavrick is busy — burst limit") not a silent drop, and fires an operator alert. Prevents single-workspace resource exhaustion from affecting other tenants.
• ⊢
  Secret scrubbing on operator alerts. Every message routed to operator Telegram passes through a 13-pattern regex scrubber before send: Bearer tokens, OpenAI sk- keys, Slack xoxb tokens, GitHub ghp_, Stripe live/test keys, AWS access keys, Meta long-lived tokens, Pipedream ctok, generic JWTs, plus our own webhook secret and bot token resolved from env. Defense against operator-alert exfiltration via log scraping or alert-channel misconfiguration.
• ⊢
  Credit-balance visibility. Workspace credit exhaustion fires an immediate operator alert AND an events.insert row at the moment of the 402, not on next-cron-rollup. The customer sees a polite "out of credits" message; we see the workspace identity and the operation that ran them out, with a human-DM follow-up budget.
• ⊢
  Backup and restore SLOs. Point-in-time database restore via Supabase PITR (7-day window on production). Documented runbook covers five recovery scenarios: single-table corruption (RTO 1h, RPO 1m), full-DB loss (RTO 4h, RPO 5m), R2 object deletion, Vercel rollback, Modal rollback. Quarterly paper drill, annual live drill.
• ⊢
  Cross-origin isolation. Strict-Transport-Security (2-year, includeSubDomains, preload), Content-Security-Policy with explicit allowlists, Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Resource-Policy: same-site applied to every response. X-Frame-Options + frame-ancestors 'none' block clickjacking. SOC 2 CC6.7 + CASA V8 alignment.
• ⊢
  Schema drift detection. CI check (scripts/check_schema_drift.ts) parses applied migrations and walks every supabase().from() / .eq() / .select() / .update() / .insert() call to verify referenced columns exist. Catches "migration drops column, code still references it" failures before deploy. Installed after the May 2026 dropped-column incident.

Each of the above resolves to a specific file path and commit hash in the Mavrick codebase. Customers under enterprise plans can request a code-review walkthrough under MNDA.

The following service providers process customer data on Mavrick’s behalf. Each is contractually bound to handle customer data per Mavrick’s Privacy Charter and applicable regulations.

Mavrick maintains a current subprocessor list with notification of material changes. Customers under enterprise plans can request notification before subprocessor changes take effect. Customers may request the most recent vendor security questionnaires under MNDA.

Mavrick publishes the underlying architecture that handles customer data. The following artifacts are public:

• •

  The Mavrick system prompt — every word the agent reads before responding. Versioned. Diffs published when material changes occur.

  Read the system prompt →
• •

  The self-improving architecture — closed-loop design, eight subsystems, seven signal channels, five guardrails. Documented in full.

  Read the architecture documentation →
• •

  The public learning ledger — every approved learning Mavrick has deployed. Includes regression status, approval timestamp, source workspace count.

  See the changelog →
• •

  The decline log — every drafted learning that was rejected by the operator approval gate. With one-line decline reason.

  See the decline log →

This level of architectural transparency is uncommon. We publish it because customers entrusting their marketing data to an AI coworker deserve to know exactly what the agent reads, what it can do, what it has learned, and what it has been prevented from learning.

Mavrick maintains a documented Incident Response Plan (IRP) aligned with SOC 2 Trust Services Criteria CC7.3, CC7.4, and CC7.5.

Process summary:

1. 1.
   Detection — Automated monitoring via Sentry; customer-reported incidents via admin@getmavrick.com.
2. 2.
   Triage — Incident classified within 4 hours of detection (severity levels P0 through P3).
3. 3.
   Containment — Isolation of affected systems within 24 hours for P0/P1; within 72 hours for P2/P3.
4. 4.
   Notification — Customers affected by a P0 or P1 security incident are notified within 72 hours of confirmation, via primary workspace contact.
5. 5.
   Resolution — Root cause analysis, remediation, and verification within 14 days of containment.
6. 6.
   Post-mortem — Written post-mortem published within 30 days of resolution. Customer-affecting incidents receive a public post-mortem; internal-only incidents receive a private one.
7. 7.
   Continuous improvement — Every incident generates lessons-learned items that feed the next quarterly compliance review.

The full IRP document is available under MNDA.

Mavrick’s compliance program runs continuously, not as a one-time audit prep effort. The following artifacts are produced on a fixed cadence and stored in the versioned Mavrick Compliance/ evidence folder, available under MNDA.

The clock started on April 15, 2026. Every month since then has a compliance review log entry. Customers and auditors can request the folder under MNDA to verify operational continuity.