Data Protection Policy
Last updated: 2026-05-24 Owner: 11978853 CANADA INC. ("Agentic Sellar") Scope: This policy governs how Agentic Sellar handles Amazon Information (as defined by Amazon's Data Protection Policy) obtained via the Amazon Advertising API and the Selling Partner API (SP-API).
This document exists to meet Amazon's requirements for SP-API Solution Providers and Ads API developers. It describes our technical and organizational measures.
1. Classification of Amazon Information We Access
| Category | Accessed? | Purpose | Storage |
|---|---|---|---|
| Advertising performance data (impressions, clicks, spend, sales, conversions, campaign/keyword/ad-group structure) | Yes | Campaign optimization | Encrypted at rest, tenant-scoped |
| Search term reports | Yes | Keyword harvesting + negation decisions | Encrypted at rest, tenant-scoped, text sanitized before LLM use |
| Order metrics (aggregate revenue, order counts, ASIN-level sales) via SP-API | Yes (if seller authorizes SP-API scope) | TACoS calculation, business-health metrics | Encrypted at rest, tenant-scoped |
| Personally Identifiable Information (PII) of end buyers (names, addresses, phone, email) | No | N/A — we do not request the PII scope | N/A |
| Shipment address data | No | N/A | N/A |
| Tax and payment data | No | N/A | N/A |
We hold ourselves out as a non-PII Solution Provider. We do not request the ConfidentialPersonallyIdentifiableInformation role on SP-API.
2. Data Flows
Amazon (Ads API + SP-API)
│
│ OAuth 2.0 (refresh token exchange) over TLS 1.2+
│
▼
Agentic Sellar API server (Vercel — US-East)
│
├── [Encrypt AES-256-GCM] → Postgres (Neon — US-East)
│ • tenant_id scoping on every query
│ • Row-level isolation in application layer
│ • Database at rest encryption (AES-256)
│
├── [Compute metrics deterministically, server-side]
│
├── [Assemble LLM prompt server-side — seller never sees this]
│ ↓
│ Proxy to seller-chosen LLM provider (Anthropic / OpenAI / Google)
│ using seller's own API key, zero-retention terms when available
│
└── [Validate LLM output → route via permission pipeline → act on Ads API]
All inter-service traffic uses TLS 1.2+. All database connections use TLS.
3. Encryption
3.1 At rest
- Seller OAuth refresh tokens, Amazon LWA client secrets, LLM API keys: AES-256-GCM with a unique random IV per record. Cipher, IV, and auth tag are concatenated with
:delimiters and stored in Postgrestextcolumns. - Database-level encryption: Neon provides AES-256 encryption at rest for the underlying storage.
- Backups: daily snapshots, encrypted, retained 30 days, access restricted to production operators.
3.2 In transit
- External: TLS 1.2+ enforced at the edge. HSTS header set with 1-year max-age on all production domains.
- Internal (app ↔ DB): TLS required, certificate-pinned to the database provider.
3.3 Key management
- The master encryption key (
CREDENTIAL_ENCRYPTION_KEY) is 32 bytes of random entropy stored in the hosting provider's secret manager. It is injected as an environment variable into the production process only. It is never logged, printed, included in error traces, or written to disk outside of memory. - Key rotation is scheduled annually. Rotation involves dual-encryption in a transition window and verification before retiring the old key.
4. Access Control
4.1 Authentication
- Seller-facing: email + bcrypt password (cost factor 12) OR bearer API keys (stored as SHA-256 hashes). Session cookies are signed and httpOnly.
- Staff (internal): SSO to hosting-provider dashboards. Database access is role-restricted (read, admin). MFA required for all staff accounts with production access.
4.2 Authorization
- Every database query is scoped by
organization_id. The scoping is enforced in thetenantQuerieshelper (seepackages/db/src/queries/tenant.ts) which every API route uses. - API routes call
requireAuth()which resolves either a session cookie or an API key to a{ userId, organizationId }tuple, and reject with 403 if the requested resource'sorgIddoesn't match. - Audit logs record every action taken on behalf of a seller: who approved it, what was executed, when, and the Amazon entity ID affected.
4.3 Staff access to production data
- Production database access is reserved to 1 named individuals.
- All production queries are logged.
- Access requires MFA and an active engineering role.
- Staff cannot decrypt seller credentials; the encryption key is available only to the production compute environment.
5. Logging, Monitoring, and Audit
- Request logs: server access logs retained 30 days. Logs are scrubbed of credential headers (Authorization, Cookie) before storage.
- Audit logs: a dedicated append-only
audit_logtable records every agent-proposed action, approval, rejection, and execution, including reasoning and Amazon entity IDs. Retained 7 years. - Error monitoring: {error monitor} receives stack traces and request context with PII fields scrubbed.
- Intrusion detection: failed-login rate limiting, API-key brute-force protection, and anomalous-query alerting.
6. Data Retention and Destruction
- Active accounts: data retained while service is active.
- Terminated accounts: all encrypted credentials deleted within 24 hours. Campaign, performance, and audit data deleted within 30 days except audit log records required for 7-year retention under financial-record rules (pseudonymized after account termination).
- Backups: automatic expiry at 30 days. Terminated-account data is purged from current backups within 30 days of termination.
- Secure destruction: Postgres
DELETEis followed by backup expiry; we do not wipe physical storage (cloud-managed).
Seller-initiated deletion requests are completed within 30 days.
7. Incident Response
7.1 Detection
Operational alerts fire on: anomalous query volumes, credential-encryption failures, repeated auth failures, staff-access to previously-unaccessed tenants.
7.2 Response plan
- Isolate: disable affected credentials and rotate impacted keys.
- Assess: determine scope — which sellers, which data, which attack vector.
- Notify Amazon: per Amazon policy, within 24 hours of discovery for any breach involving Amazon Information.
- Notify affected sellers: within 72 hours via email with what was accessed and what we're doing about it.
- Notify regulators: per GDPR (within 72 hours) and state breach-notification laws where applicable.
- Remediate: patch the root cause, rotate any potentially compromised secrets globally.
- Post-mortem: internal report within 14 days, public redacted version within 30 days for significant incidents.
7.3 Contact
- Security incidents: security@agenticsellar.com (monitored 24/7)
- Amazon policy contact: support@agenticsellar.com
8. Sub-processors
| Sub-processor | Role | Data categories | Location |
|---|---|---|---|
| Vercel (Vercel) | Compute | Application logs, encrypted credentials in transit | US |
| Neon (Neon) | Database | All stored data (encrypted at rest) | US |
| Inngest | Background job queue | Event payloads (no credentials in payload) | US |
| {payment processor} | Subscription billing | Seller contact + billing data | US |
| {error monitor} | Error tracking | Stack traces, scrubbed request data | US |
| LLM providers (Anthropic, OpenAI, Google) | Model inference, per seller's chosen provider | Pre-computed metrics + strategy fragments sent with seller's API key | US |
We maintain DPAs with each sub-processor. We notify sellers 30 days before adding a new sub-processor handling Amazon Information.
9. Third-Party Software
- All NPM and OS dependencies are pinned and scanned via Dependabot.
- Critical CVEs are patched within 72 hours of disclosure.
- We do not embed any third-party analytics, advertising, or tracking SDKs in server-side code that touches Amazon Information.
- Client-side analytics (e.g., {analytics provider}) are limited to page-view and UX metrics; they do not receive Amazon Information.
10. Personnel
- Every employee with access to production systems signs a confidentiality agreement and completes annual security training covering Amazon policy, phishing, credential handling, and the response plan above.
- Background checks are conducted on all personnel with production access, where permitted by local law.
- Access is revoked within 24 hours of role change or termination.
11. Physical Security
We operate entirely on cloud infrastructure. We do not run on-premises servers.
- Vercel and Neon attest to SOC 2 Type II compliance covering physical data-center security.
- Staff workstations are required to have: full-disk encryption, automatic screen lock, managed via {mdm tool}.
12. Audit and Review
- This policy is reviewed annually and whenever a material change to the system architecture is made.
- Penetration testing: {pentest frequency} by {pentest vendor}.
- Internal audit: quarterly, covering access logs, key rotation status, and policy adherence.
13. Policy Violations
Employees who violate this policy are subject to disciplinary action up to and including termination. Violations involving Amazon Information are reported to Amazon in addition to internal remediation.
14. AI/LLM-Specific Controls
Because our optimization engine uses large language models, we implement additional controls:
14.1 Data minimization before LLM calls
- We send aggregate pre-computed metrics to the LLM, not raw order data, not PII, not raw API responses.
- Example: the LLM sees "keyword 'wireless earbuds' has ACoS 42% over 14 days, 234 clicks, 12 orders" — it does not see which individuals placed the orders, shipping addresses, payment information, or any customer identifiers.
- Search-term strings are the only user-generated input that reaches the LLM. These are sanitized before inclusion (see 14.2).
14.2 Prompt-injection defense
- Search-term text is truncated to 128 characters, stripped of control characters, zero-width characters, and directional override characters.
- Instruction-like tokens (e.g., "ignore previous instructions", "system:") are neutralized.
- The system prompt is constructed entirely server-side; no user-supplied text is interpolated into it with interpreter privileges.
14.3 Output validation
Every LLM output is validated BEFORE any action is taken on the seller's Amazon account:
- Zod schema validation ensures structural compliance.
- Numerical guardrails reject bid values outside 0.02-1000, budget values outside 1-100,000, etc.
- A leakage scanner rejects outputs that contain verbatim strings from our internal strategy framework (protects Agentic Sellar's IP).
- The permission pipeline routes each proposed action to auto-execute, require-approval, or blocked per the seller's configured permission level.
14.4 Model choice and retention
- Under our bring-your-own-LLM model, the seller chooses the provider (Anthropic, OpenAI, or Google) and supplies their own API key.
- We do not log prompts or completions beyond the duration of a single cycle.
- We recommend sellers enable zero-data-retention options on their chosen provider. We provide documentation explaining how.
14.5 We do NOT
- Train models on Amazon Information.
- Use Amazon Information to fine-tune prompts shared across tenants.
- Share prompts, completions, or the underlying strategy documents outside our server environment.
15. Contact
Data Protection Officer: privacy@agenticsellar.com Security: security@agenticsellar.com Amazon Policy Compliance: support@agenticsellar.com
Legal Entity: 11978853 CANADA INC. Mailing Address: 225 Walmer Road, Toronto, ON M5R 3P7, Canada