Data Protection Policy

Last updated: 2026-10-19 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

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)
   │
   ├── [Live MCP / REST read] → authorized AI client or API caller
   │
   ├── [Confirmed write] → scope + account + plan + confirmation checks
   │                     → Amazon API → call receipt
   │
   ├── [Eligible retained history] → Postgres (Neon , US-East)
   │                                • organization_id scoping
   │                                • application-layer tenant isolation
   │                                • database encryption at rest
   │
   ├── [Temporary Ads report] → encrypted storage/database → expires after 72h
   │
   └── [Optional automation] → minimized metrics → seller-chosen LLM provider
                               → validate output → permission pipeline

All inter-service traffic uses TLS 1.2+. All database connections use TLS.

3. Encryption

3.1 At rest

• Seller OAuth refresh tokens, Amazon application secrets, and optional LLM API keys: AES-256-GCM with a unique random IV per encrypted value. Ciphertext and authenticated-encryption metadata are stored in Postgres.
• 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 is required for database connections.

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), signed httpOnly sessions, or bearer API keys stored as hashes.
• AI clients: OAuth 2.1 authorization-code flow with PKCE. Grants bind allowed scopes and Amazon accounts; access and refresh token values are stored as hashes and expire or can be revoked.
• 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

• Tenant-owned records carry an organization_id, and request handlers verify membership or an approved agent-account binding before querying or mutating those records. Shared query helpers and route-level filters enforce this boundary.
• Dashboard and REST routes resolve a session or API key to a user and organization. Agent routes resolve a hashed token to an unexpired, unrevoked grant with explicit scopes and Amazon-account bindings.
• MCP and REST calls create receipts recording the grant, organization where applicable, operation, account binding, data source, work units, status, and timestamp. Optional automation actions use the action audit log.

4.3 Staff access to production data

• Production database access is reserved to a limited number of 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.
• Call receipts: the agent_calls table records MCP and REST operation metadata and status; it does not store the Amazon response body.
• Automation audit logs: the audit_log table records optional agent-proposed actions, approval state, execution state, and affected entities. Records subject to financial-record requirements are retained for up to 7 years.
• Error monitoring: Our hosting platform's log streams (Vercel) receive 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

• Access-plan operations: live responses are returned to the caller without being added to retained analytics. Generated advertising reports expire after 72 hours.
• Data plans: supported non-PII history is retained for active, marketplace-specific ASIN selections for up to 13 months.
• Downgrades and deactivation: affected retained history remains recoverable for 90 days before deletion unless the seller requests earlier deletion.
• Active accounts: account and configuration data are retained while the service is active.
• Terminated accounts: encrypted credentials are deleted within 24 hours. Other account and retained Amazon data are deleted according to the Privacy Policy's account-deletion and 90-day retained-history schedules, except records that must be kept for security, billing, disputes, or legal obligations; those records are minimized or pseudonymized where practical.
• Backups: automatic expiry at 30 days. Terminated-account data is purged from current backups within 30 days of termination.
• Secure destruction: Postgres DELETE is 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

1. Isolate: disable affected credentials and rotate impacted keys.
2. Assess: determine scope , which sellers, which data, which attack vector.
3. Notify Amazon: per Amazon policy, within 24 hours of discovery for any breach involving Amazon Information.
4. Notify affected sellers: within 72 hours via email with what was accessed and what we're doing about it.
5. Notify regulators: per GDPR (within 72 hours) and state breach-notification laws where applicable.
6. Remediate: patch the root cause, rotate any potentially compromised secrets globally.
7. 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: security@amazon.com

8. Sub-processors

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.
• Vercel Analytics measures public page views and a small set of conversion events. Analytics properties exclude Amazon Information, credentials, email addresses, and API response bodies.
• First-touch UTM values, landing path, and referring host remain in browser session storage until signup and are not stored in advertising cookies.

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 and automatic screen lock, enforced by company policy.

12. Audit and Review

• This policy is reviewed annually and whenever a material change to the system architecture is made.
• Penetration testing: planned at least annually by a qualified third-party security vendor as the platform scales.
• 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 Client and LLM-Specific Controls

The managed MCP and REST service can return data to a third-party AI client chosen by the seller. Optional automation features can also use a seller-configured model provider. We apply the following controls:

14.1 Data minimization before LLM calls

• For optional model-backed features, we send aggregate pre-computed metrics where practical, not credentials, end-buyer PII, shipment addresses, or raw order records.
• 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 can be included when required by an enabled analysis feature and 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.
• Optional automation prompts are constructed server-side; user-controlled strings are treated as data rather than trusted instructions.

14.3 Output validation

Every optional automation output is validated before it can enter an Amazon action workflow:

• 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 according to the seller's configured permission level. Separately, MCP and REST writes require a write scope and confirm=true on every call.

14.4 Model choice and retention

• The core MCP and REST connection does not require an LLM API key. If a seller enables an optional model-backed feature, the seller chooses the provider (Anthropic, OpenAI, or Google) and supplies the API key.
• We do not persist optional feature prompts or completions beyond the processing cycle.
• A connected AI client independently controls its own retention. Sellers should review that provider's privacy and data-control settings before granting access.

14.5 We do NOT

• Train models on Amazon Information.
• Use Amazon Information to fine-tune prompts shared across tenants.
• Share credentials, server secrets, or end-buyer PII with connected AI clients or optional model providers.

15. Contact

Data Protection Officer: privacy@agenticsellar.com Security: security@agenticsellar.com Amazon Policy Compliance: security@amazon.com

Legal Entity: 11978853 CANADA INC.