// trust center
Security posture, in plain text.
Magistry writes directly to your live systems. We treat that as a responsibility, not a feature. Everything we do to keep your data and your store safe is documented here, in language you can forward to a security team without an interpreter.
// compliance
Where we stand today.
GDPR
Where we process personal data on behalf of a customer we act as a processor under a DPA available to every paying tenant. EU-based infrastructure, data-subject request support, and sub-processor transparency. Privacy questions: privacy@magistry.io.
// Data Processing Addendum available
Ask usPayments (PCI)
Magistry never stores, processes, or transmits cardholder data. All billing and payments run through Shopify — card data never touches Magistry infrastructure.
// Handled by Shopify
Ask usData residency
Primary data stores run on EU-based infrastructure. Encryption in transit and at rest, secrets isolated in Supabase Vault, and multi-tenant isolation enforced at the database level.
// Supabase Postgres · EU region
Ask usSOC 2
We're an early-stage company and are not SOC 2 certified today. We build to the same controls — least privilege, encryption, and audit logging — and will pursue formal certification as we grow. Happy to walk a security team through our current posture.
// Early-stage — no formal audit yet
Ask us// data handling
Where your data lives and how we protect it.
Encrypted at rest, encrypted in transit
AES-256 at rest on all primary and replica databases. TLS 1.3 in transit, including service-to-service inside our VPC. Backups encrypted with separate keys.
Vault-encrypted secrets
Per-tenant API credentials live in Supabase Vault, encrypted at rest, and are read by the worker when a job needs them. A credential that stops working is flagged so you can rotate it.
Never trained on customer data
Magistry does not train models on your store data, your CS replies or your brand-voice embeddings. Every model provider we send data to is listed as a sub-processor.
Audit log of every write
Every change Magistry makes on your behalf is a row in the decision_log, with the evidence behind it and the operation that reverses it, so each state change can be traced back to the decision that made it.
// access controls
Who can see what, and how we enforce it.
RBAC across every surface
Owner, Admin, Staff, Viewer. Store access is enforced in the database through row-level security, not just the UI, and a third-party app on the API is limited to the stores and write access it was granted.
Secrets in Supabase Vault
Per-tenant API credentials and connected-service tokens live encrypted in Supabase Vault, decrypted only by the worker that needs them for a specific job. SAML SSO and SCIM provisioning are available on Enterprise workspaces.
Per-tenant isolation
Postgres row-level security is enabled on every table, and every store-scoped read goes through the same access check, so one tenant cannot read another's rows.
Advisory locks
Concurrent writes against the same resource are serialised through Postgres advisory locks. Two agents will never race on a single SKU, a single ad set, or a single CS thread.
// sub-processors
Everyone we share data with.
Shopify
Commerce platform + billing/payments (card data never reaches Magistry)
Global · payments handled by Shopify
Request DPASupabase
Postgres + auth + storage + Vault for secrets
EU region
Request DPAVercel
Dashboard + marketing site hosting
Global edge · EU primary
Request DPARailway
Worker + scheduled job runtime
EU-West
Request DPAAnthropic
Language model inference
US · no training on customer data
Request DPAOpenAI
Language model inference
US · no training on customer data
Request DPAResend
Transactional email delivery
EU/US
Request DPASentry
Application error monitoring
EU instance
Request DPADataForSEO
Search + market data for the Researcher
US
Request DPA
// incident response
What happens when something breaks.
We're a small team and we monitor the platform with error tracking and alerting. If something breaks, we work it promptly and keep affected customers informed directly.
For a personal-data incident, we notify affected tenants without undue delay and within the timelines the GDPR requires, with the scope, timeline, remediation, and the rows touched in the decision log.
The kill switch is operator-owned. Any operator can stop every autonomous write across their tenant from one flag — write jobs refuse to start while it's on — and the switch state is itself logged.
Report an incident
Suspect a vulnerability or saw a write you cannot explain? Email us — we welcome responsible disclosure and will work with you on any confirmed report.
// contact
Talk to our security team.
Send the questionnaire, ask for the report, or schedule a call with the engineer who owns the gate. We reply inside one business day.
privacy@magistry.io · privacy + DPA requests