Mission Control — Security & Trust Overview

Document: Security & Trust Overview Version: 1.0 Effective Date: 2026-06-01 Entity: SellerSlice LLC (Washington State, USA) Product: Mission Control ("the Service") Owner: SellerSlice Security & Privacy function Review cadence: Reviewed at least annually and on any material change.

TL;DR — The plain-language version

You are an Amazon-seller agency client (or you work at one), and you are about to hand us data that runs your business. Here is the short version of how we treat it.

• We are built on serious infrastructure. Mission Control runs on Vercel (hosting) and Supabase (database, auth, storage). Supabase is AWS-backed; Vercel runs on managed cloud infrastructure. Our intended posture is encryption in transit (TLS 1.2+) and at rest (AES-256) — see §4 for what is confirmed vs. pending evidence.
• Your data is designed to be walled off from every other client. We use database-level row-level security (RLS) and role-checked access so the Service is designed so that one client cannot access another client's data.
• We hold no Amazon buyer personal data. We use no Restricted SP-API roles, so we never receive buyer names, addresses, emails, or phone numbers.
• When you disconnect, your Amazon data is deleted — not "anonymized." On de-authorization, disconnection, or account closure, we destroy your Amazon Information within 30 days, to the NIST 800-88 standard. Anonymization is not a substitute, and we do not treat it as one.
• Your Amazon data is never pooled, benchmarked, or shown to anyone else. It is used solely to serve your business. We do not aggregate it across clients, and we do not use it — or any of your data — to train any AI model.
• AI is advisory. Our AI features (copywriting, Marketing-Ready scoring, report generation, Morning Review) suggest; a human reviews before any action touches your Amazon account.
• We disclose every sub-processor, including which ones touch Amazon Information. See /subprocessors.
• We move fast on incidents. Amazon gets notified within 24 hours of a confirmed security incident; regulators and affected people get notified on the clocks the law sets.

If something below matters to your diligence, email legal@sellerslice.com (commercial/contract), privacy@sellerslice.com (data rights and privacy), or help@sellerslice.com (everything else).

Table of Contents

1. About this document
2. Who we are and what Mission Control is
3. Hosting and infrastructure
4. Encryption
5. Tenant isolation and access control
6. Authentication and identity
7. Amazon data handling (the part sellers care about most)
8. Artificial intelligence
9. Sub-processors and supply chain
10. International data transfers
11. Data retention and deletion
12. Logging, monitoring, and audit
13. Vulnerability management and secure development
14. Incident response and breach notification
15. Backups, availability, and resilience
16. Personnel, access governance, and deprovisioning
17. Your data rights and how to exercise them
18. Compliance posture by jurisdiction
19. Assurance artifacts and how to request them
20. Contacts
21. Disclaimer and limitations
22. Changelog and version history

1. About this document

This Security & Trust Overview summarizes the technical and organizational measures (TOMs) SellerSlice LLC applies to protect data in Mission Control. It is written for the people who do diligence on us: agency owners deciding whether to connect their Amazon accounts, their procurement and security teams, and the regulators and counsel who may ask how we operate.

This is a trust document, not a binding instrument. The legally operative commitments live in:

• the Privacy Policy (v2.1) — what we collect, why, who we share with, and your rights;
• the Terms of Service (v2.3) — the commercial agreement;
• the Data Processing Agreement (v1.0) — our Article 28 / APP 8 / Quebec s. 17 processor commitments, including the formal TOMs annex;
• the Sub-processor list, Cookie Policy, Data Retention Schedule, AI Disclosure, and Acceptable Use Policy.

Where this overview and any of those documents conflict, those documents control. This page does not create warranties; the disclaimers in §21 and the Terms of Service apply. Controls marked as target are intended posture that must be evidenced before external reliance.

2. Who we are and what Mission Control is

SellerSlice LLC is a Washington State limited liability company. Mission Control is our B2B SaaS platform: an internal operations system for our agency team plus a client portal for the Amazon-seller brands we serve. It is for businesses and people aged 18 and over; it is not a consumer product and is not directed to children.

Our roles under data-protection law. SellerSlice acts as a controller for the data it determines the purposes of — its own user accounts, billing, employee, and audit records — and as a processor / service provider for the client-portal data and Amazon-sourced information it handles on behalf of each agency client (who is the controller of their own seller data). For payment data, Stripe acts as an independent controller. See the DPA for the formal controller/processor mapping.

3. Hosting and infrastructure

Mission Control runs on two primary platforms:

Supabase is AWS-backed. Vercel runs on managed cloud infrastructure (multi-cloud; not exclusively AWS). We do not operate our own physical data centers. Physical and environmental security for the underlying infrastructure is inherited from our platform providers, who maintain their own independent compliance certifications. We layer our application-level controls (encryption, RLS, access governance, logging) on top.

4. Encryption

The following describes our intended encryption posture. Items marked for confirmation must be evidenced before external reliance.

• In transit: All connections to Mission Control are intended to be encrypted with TLS 1.2 or higher.
• At rest: Application data is intended to be encrypted at rest with AES-256 by our database and storage providers.
• Amazon credentials specifically: OAuth refresh tokens and other Amazon connection secrets are encrypted at the application layer with AES-256-GCM (NIST SP 800-38D nonce sizing) before storage — never in plaintext, and never exposed to browser code (lib/amazon/encryption.ts). An encryption_key_version column supports key rotation without bulk decryption.
• Key management: Encryption keys are managed by the platform providers and our application key-management configuration. Target rotation cadence for application-level keys is annual at minimum, consistent with Amazon DPP expectations.

The service-role database key and other privileged secrets are held server-side only and are never shipped to the browser.

5. Tenant isolation and access control

Mission Control is multi-tenant, and keeping tenants separate is a first-order design requirement, not an afterthought.

• Row-Level Security (RLS): Tenant separation is enforced in the database itself with Postgres Row-Level Security policies, so a query for one client is designed not to return another client's rows even if application code is wrong.
• Role-in-token authorization: A user's role is carried in the authenticated JWT's app_metadata (the server-controlled, non-user-editable claim) and is the basis for RLS policy decisions. Roles are kept in sync between the application user record and the auth provider's app-metadata.
• Separation of employee and client surfaces: The employee/admin application and the client portal are distinct route groups with distinct role gates. Clients do not see employee pages.
• Amazon data is per-client by construction. Amazon Information is tagged to a specific (client, region) and is only ever accessible in service of that client. It is never aggregated across clients, never used for cross-client benchmarking, and never disclosed to another client — consistent with Amazon AUP §4.4 / §4.6 and the Solution Provider Agreement §D-7.1 / §D-7.5.

This design goal is not an absolute guarantee against all risk; see §21.

6. Authentication and identity

The following describes intended authentication posture. Enforcement items marked for confirmation must be evidenced; see also the access-governance reconciliation in §16.

• Authentication is handled by Supabase Auth.
• Multi-factor authentication (MFA) is available; our target is that MFA is required (enforced) for employee/staff accounts that can access client or Amazon data.
• Employee password policy: target minimum 12 characters.
• Amazon connections are authorized per-client via OAuth (SP-API and Advertising API). We do not use shared Amazon credentials, and our Acceptable Use Policy prohibits clients and staff from sharing credentials, consistent with the Amazon Data Protection Policy.
• Google Calendar / Meet integration is per-user OAuth (two-way sync), scoped to that user's own calendar; it does not touch Amazon data.

7. Amazon data handling (the part sellers care about most)

If you are handing us SP-API or Advertising API access, this is the section that matters. Our handling of Amazon data is governed by the Amazon Data Protection Policy (DPP), the Acceptable Use Policy (AUP), and the Solution Provider Agreement (SPA) (text effective 25 Nov 2025).

7.1 We hold no Amazon buyer personal data

We use no Restricted SP-API roles. As a result, we never receive buyer personally identifiable information — no buyer name, address, email, or phone number ever enters Mission Control. The PII-specific obligations under the DPP (the 30-day-after-delivery buyer-PII purge, Restricted-role controls) are therefore moot for us — but we state the standard anyway, and if any data path ever changed, the full PII regime would re-attach.

7.2 What we do retain — and only while you are connected

We retain per-client listing and performance metrics — including before/after change-impact data — while your authorization is active and for no longer than the ≤18-month ceiling described in §11 (Non-PII Amazon Information), solely to serve your business (catalog, orders, sales/settlement/financial figures, ad metrics, ASIN data). This is what powers your reports, your P&L, your Buy Box analysis, and your Marketing-Ready scoring. The retention bound here is identical to §11; regardless of the ceiling, all of it is deleted on de-authorization per §7.3.

7.3 Deletion on disconnect — destroyed, not "anonymized"

On de-authorization, disconnection, or account closure, we delete your Amazon Information within 30 days. Specifically:

• We hard-delete (or null-then-delete) the encrypted credential/refresh-token record; and
• We cascade-purge all ingested Amazon Information for that (client, region) — catalog, orders, sales, settlement/financial, ad metrics, ASIN data, and Data Kiosk outputs.

This is a real, destructive deletion aligned with NIST SP 800-88 (Clear/Purge). Orphaning data or removing pointers is not an acceptable deletion under the DPP, and we do not rely on it. Anonymization is categorically NOT a substitute for deletion of Amazon Information, and we do not treat it as one. (Anonymized-retention carve-outs in our Privacy Policy apply only to non-Amazon business records.)

There is no business-convenience carve-out from Amazon-data deletion. Amazon Information is deleted on de-authorization full stop. The only exception is data we are narrowly and specifically required by law to retain; any such data is access-restricted, segregated, and held only for the period the law requires, then destroyed. To be clear: tax and billing records are a SEPARATE, non-Amazon category (7-year retention — see §11); they are not, and may not be cited as, a carve-out from the categorical duty to delete Amazon Information.

7.4 Never pooled, never benchmarked across clients

Your Amazon data is used solely to support your own business with Amazon. We do not aggregate it across clients, do not use it for cross-client benchmarking shown to other clients, and do not disclose it to other clients — consistent with AUP §4.4 / §4.6 and SPA §D-7.1 / §D-7.5. This prohibition survives de-identification and aggregation: the test is who benefits, not whether the data is identifiable.

7.5 Never used to train AI

Amazon Information is never used to train, fine-tune, or improve any AI/ML/LLM model, and that prohibition is flowed down contractually to our AI sub-processors. See §8.

7.6 Scope minimization and misuse reporting

We request only the API scopes our features need (data minimization, per AUP §3.8). We reserve the right to suspend access for misuse, and we will report suspected misuse to Amazon through the current Amazon abuse-reporting channel where appropriate (AUP §1.3).

7.7 Amazon security incident point of contact

We maintain an Information Security Point of Contact (IMPOC), reachable at help@sellerslice.com, for Amazon's security@amazon.com channel and notify Amazon within 24 hours of a confirmed security incident affecting Amazon Information (DPP §1.6). See §14.

8. Artificial intelligence

Mission Control uses AI to assist our team and clients. Our full disclosure lives at /ai; the security-relevant points:

• AI is advisory / decision-support. AI features — copywriting and copy research, Marketing-Ready scoring, AI report generation, and the internal Morning Review/News brief — produce suggestions. A human reviews and can edit or reject any AI output before it drives an action against your Amazon account. No AI feature makes a legally or similarly significant automated decision about an individual (GDPR Art. 22; Quebec Law 25 art. 12.1; AU automated-decision framework).
• We do not train models on your data. We do not use Customer Data or Amazon-sourced data to train, fine-tune, or improve any third-party model, and this prohibition is flowed down to our AI sub-processors contractually.
• Four AI layers are live: Anthropic (copy generation/research), OpenAI (scoring/embeddings), xAI/Grok (web/X search for the internal Morning Review/News only — not client-data processing), and the Vercel AI Gateway (inference routing). Listing content sent to Anthropic or OpenAI — and transiently carried by the Vercel AI Gateway when it routes those prompts — is transient prompt content; it is not retained for training and contains no buyer PII (we hold none — see §7.1).
• No-training substantiation is pending vendor confirmation.

9. Sub-processors and supply chain

We publish a complete, versioned sub-processor list at /subprocessors with a "Last updated" date, a change-notice mechanism, and a 30-day advance notice + objection window (matching the DPA). The list flags which sub-processors touch Amazon Information and, for AI vendors, the input-retention term. As of the effective date:

Every sub-processor that handles personal data or Amazon Information is bound by a written agreement requiring confidentiality, appropriate security, and — for AI vendors — the no-training flow-down. These agreements are also the mechanism by which we discharge Australia APP 8.1 "reasonable steps" (and accept s 16C accountability for our US providers) and Quebec Law 25 s. 17 transfer obligations. Each new US sub-processor also triggers a fresh Quebec Law 25 s. 3.3 privacy impact assessment before onboarding (see §18.3).

10. International data transfers

Mission Control serves clients across the United States, United Kingdom, European Union, Canada (including Quebec), Mexico, and Australia. Because our core stack is US-based, we rely on the following transfer mechanisms (see the Privacy Policy §7 and the DPA cross-border annex for the authoritative per-recipient detail):

We maintain a documented Transfer Impact Assessment for EU/UK transfers.

11. Data retention and deletion

Full detail is at /data-retention. Summary of the key periods (all cited Amazon DPP/AUP/SPA section numbers are subject to the global re-verification note below):

Deletion is real and cascades across our data stores, including the shared legacy database that Mission Control and the prior system both use.

12. Logging, monitoring, and audit

• Audit logging of authentication and access-sensitive events is retained for at least 12 months, meeting the Amazon DPP floor.
• Operational alerting: Security- and ops-relevant events route to our internal alert channel (#mc-alerts) via a watchdog process, so on-call staff are paged on anomalies.
• Logs are access-restricted to authorized personnel and are themselves subject to the access governance in §16.

13. Vulnerability management and secure development

The cadences below are targets, not yet evidenced; specific numbers are stated inside confirmation brackets and must be operationally true before external publication.

• TypeScript strict mode and lint checks gate code; the build fails on type errors.
• Vulnerability scanning on a recurring cadence (target every 30 days).
• Penetration testing (target annual).
• Remediation targets (target critical within 7 days, high within 30 days), aligned with Amazon DPP expectation.
• Dependency hygiene via platform-managed and automated dependency review.
• Secrets management: privileged keys (service-role DB key, Amazon credential encryption keys) are server-side only and never exposed to client code.

14. Incident response and breach notification

We maintain an incident-response runbook covering six distinct notification clocks — we keep them separate and do not conflate them:

We maintain a confidentiality-incident register that logs every incident of any severity, the harm assessment, and the action taken — satisfying Quebec s. 3.8 and PIPEDA SOR/2018-64 simultaneously and retained for at least 24 months.

15. Backups, availability, and resilience

Resilience specifics below are target / to-be-confirmed and must be filled before this page claims a resilience posture.

• Backups: Application data is backed up by our database provider on its managed schedule.
• Recovery objectives: RPO/RTO targets to be stated once defined.
• Availability: The Service is provided on an "as available" basis; we do not publish a contractual uptime SLA at launch, and uptime of third-party APIs (Amazon SP-API, Advertising API, Google) is outside our control. See the Terms of Service warranty disclaimer.

16. Personnel, access governance, and deprovisioning

Several controls below are target posture; the access-governance reality must be reconciled before MFA/access claims elsewhere (see §6) are asserted as fact.

• Need-to-know access. Staff access to client and Amazon data is governed by role, on a job-duty basis, consistent with the Amazon DPP's need-to-know principle. Reconciliation note: our current operating reality includes relatively broad employee access; bringing this into strict need-to-know alignment is in progress.
• Quarterly access reviews (target cadence).
• Deprovisioning of departed personnel — target within 24 hours.
• MFA + 12-character minimum for staff accounts (target — see §6).
• Confidentiality obligations bind all personnel.

17. Your data rights and how to exercise them

You can exercise data-subject and consumer-privacy rights regardless of where you are. Full detail is in the Privacy Policy §6; the security-relevant mechanics:

• How to submit: use the data-request form or email privacy@sellerslice.com — at least two methods, no account required to ask.
• Notice at Collection: we provide a CCPA/CPRA Notice at Collection at the point of signup; see the Privacy Policy for the categories and purposes.
• Authorized agents may submit on your behalf, and we verify identity before acting.
• Appeal path: if we decline a request, you may appeal (we honor the appeal mandate in CCPA/CPRA and the VA-model state laws).
• Response times: generally within 30 days (up to 45 for some US states); Mexico ARCO requests are handled on the distinct 20-business-day response / 15-business-day implementation timers.
• Global Privacy Control (GPC): we honor browser GPC signals as a binding opt-out of any sale/share and targeted advertising — and, for this product specifically, as a signal to disable non-essential analytics. You may affirmatively re-enable analytics in the cookie preference center; doing so overrides the GPC default for the analytics category only. Re-enabling analytics does not lift the sale/share or targeted-advertising opt-out — GPC continues to bind sale/share and targeted advertising regardless. We do not sell or share your personal information.
• Request integrity: the verification-token step for rights requests is rate-limited, uses constant-time comparison, and expires, so the rights portal cannot be abused for data exfiltration or malicious deletion (GDPR Art. 5(1)(f) / Art. 32).

18. Compliance posture by jurisdiction

Mission Control is offered to clients in the United States, United Kingdom, European Union, Canada (including Quebec), Mexico, and Australia from launch. We map our posture to each regime; the binding detail is in the Privacy Policy and DPA.

18.1 United States (federal + state)

• No sale or share of personal information; GPC honored (§17).
• CCPA/CPRA (California) — including the California-specific coverage of B2B contacts and employees — plus Virginia, Colorado, Connecticut, Texas and other state laws, with access/correct/delete/portability/opt-out rights, a Notice at Collection at signup, and an appeal path.
• Auto-renewal (ROSCA + state ARLs): point-of-charge disclosure, a separate unchecked affirmative-consent box, and easy click-to-cancel. Subscription-consent proof retained per California ARL.

18.2 European Union (GDPR) and United Kingdom (UK GDPR)

• Per-purpose Article 6 lawful bases; data-subject rights (Arts. 15–22); Art. 21 right to object to direct marketing; Art. 33 72-hour breach clock.
• EU Article 27 representative: To be appointed.
• UK representative: To be appointed.

18.3 Canada — PIPEDA + Quebec Law 25

• PIPEDA meaningful consent (what / with whom / why / risk of harm), naming our US processors (Supabase, Vercel, Resend, Stripe, and our AI vendors) and US storage; OPC breach reporting at real-risk-of-significant-harm with a ≥24-month record.
• Quebec Law 25: published Person in charge of the protection of personal information (privacy officer) — Jordache Perozzo, President (privacy@sellerslice.com).
• Quebec s. 17 transfer PIA + written agreement before any Quebec PI reaches the US stack; portability, de-indexing/erasure, and the right to contest automated decisions (art. 12.1).
• Quebec s. 3.3: a fresh privacy impact assessment is triggered for every new system or US sub-processor before it is onboarded, in addition to the s. 17 transfer PIA.

18.4 Mexico — LFPDPPP

• Spanish-language Aviso de Privacidad naming SellerSlice LLC + a domicilio, separating necesarias from voluntarias purposes, with transfer accept/reject for our US sub-processors (Supabase, Vercel, Resend, Stripe, and our AI vendors).
• A named internal privacy contact / Departamento de Datos Personales (may reuse the existing privacy contact). ARCO timers per §17. Breach notice to titulares "de forma inmediata" where patrimonial or moral rights are significantly affected (see §14).

18.5 Australia — Privacy Act 1988 + APPs

• Treated as a covered APP entity from day one (the small-business exemption is not relied upon). APP 5 collection notice and APP 1/APP 8 disclosure naming the United States as the likely recipient country.
• APP 8.1 "reasonable steps" via enforceable sub-processor DPAs; s. 16C accountability for US providers is accepted, not disclaimed. NDB runbook per §14. Automated-decision disclosure readiness (by 10 Dec 2026).
• Statutory tort for serious invasions of privacy (commenced 10 June 2025): we treat our cross-client isolation, need-to-know access, and no-cross-client-disclosure controls as directly relevant to limiting exposure under this tort, and we account for it in our Australian risk posture.

18.6 EU AI Act

• We are preparing in-product AI transparency labeling for the Art. 50 applicability date of 2 Aug 2026. This is a readiness statement, not a representation that labeling is already shipped. See /ai.

19. Assurance artifacts and how to request them

At launch, SellerSlice does not hold an independent SOC 2 or ISO 27001 certification of its own. We rely on the certifications and audit reports of our infrastructure providers (Vercel, Supabase, Stripe) and on the controls described in this document and the DPA TOMs annex.

For enterprise diligence, we can provide on request (under NDA where appropriate):

• our completed security questionnaire,
• our sub-processor register and change-notice subscription,
• the DPA with TOMs and transfer annexes,
• our infrastructure providers' relevant compliance reports (where redistribution is permitted).

Contact legal@sellerslice.com to begin diligence.

20. Contacts

21. Disclaimer and limitations

This Security & Trust Overview is provided for informational and diligence purposes. It describes our security posture in good faith as of the effective date and is subject to change as our systems and the threat landscape evolve.

• Not a contract or warranty. Nothing here creates a representation, warranty, guarantee, or service-level commitment. The Service is provided "as is" and "as available" per the Terms of Service. No security program eliminates all risk; we do not warrant that the Service is impenetrable or error-free.
• Target vs. evidenced controls. Where a control is described as a target or intended posture, it is not represented as currently implemented. Only controls stated without such qualification are represented as operationally true, and even those are described in good faith and not as warranties.
• Not legal advice. The legal-compliance summaries here are plain-language descriptions, not legal conclusions, and require sign-off by licensed counsel (Washington-qualified for the contract spine; data-protection counsel for the EU/UK/Canada/Quebec/Mexico/Australia regimes) before external reliance.
• Controlling documents govern. Where this overview conflicts with the Privacy Policy, Terms of Service, or DPA, those documents control.

22. Changelog and version history

We will update this document on any material change, post a dated entry above, and maintain a previous-versions archive.

Mission Control is a product of SellerSlice LLC, a Washington State limited liability company. © 2026 SellerSlice LLC.