Security posture

Three principles. Held seriously.

Seller Foundation touches a seller's Amazon account. That's a serious responsibility. This page is the short, specific version of how we hold it — and why our architecture means you don't have to take our word for most of it.

In plain English
  • Your sales, ad spend, inventory, and listings stay at Amazon. We don't keep a copy.
  • We can see your business numbers — never your buyers' names, addresses, or messages.
  • Each skill is written so Claude asks you before any write. It proposes the exact change and waits for your OK.
  • Cancel any time and the Amazon connection is cut immediately at Amazon's end.

The technical version is below, for the curious and for our auditors.

Principle 01

Stateless by design.

We don't warehouse your Amazon data. Your sales, ad spend, inventory, and listings stay at Amazon. Every question Claude asks hits Amazon fresh, via our connector, and the answer lands in your Claude session — nothing lingers in a database of ours.

Principle 02

Scoped to the business, not the buyer.

Our skills are scoped to the business-operations surface of SP-API and the Ads API — listings, inventory, pricing, campaigns, aggregated sales. We don't pull buyer names, addresses, messaging, or contact details. The endpoints that expose that data are simply not wired into any skill.

Principle 03

Claude asks before it writes.

Every skill is written so Claude proposes the change to you first — SKU, value, scope — and waits for an explicit OK before it sends anything to Amazon. The confirm step is a model-level convention, not a server-side gate; if you want a hard record of what actually changed, Amazon's own Seller Central activity log is the source of truth.

How it actually works

The data path, end to end.

  1. You install Seller Foundation in Claude. The plugin reaches a connector we run.
  2. You authorise Amazon via standard Login with Amazon. The redirect lands at our callback (auth.lumitec.ai/callback); we receive a refresh token and store it encrypted at rest in our backend (AES-256-GCM envelope encryption). Your Claude session never sees the token directly.
  3. When you ask Claude a question, our backend decrypts the refresh token in memory, exchanges it with Amazon for a short-lived access token, calls SP-API or the Ads API over TLS 1.3, strips any incidental PII, and returns the response to Claude. The access token is discarded as soon as the call completes.
  4. Claude summarises or transforms the response in-session. If the skill proposes a write, the diff is shown to you before anything is sent.
  5. Nothing about the Amazon payload — sales data, listings, ad spend — is persisted server-side by us.
Specifics

Details, as short as they can be.

Data at rest
We store the minimum required to run a licensed product: your email, billing profile, license state, and the encrypted Amazon refresh token. We do not store your Amazon business data (sales, inventory, ads, listings, orders).
Credentials
Amazon refresh tokens are stored in our backend, encrypted at rest with AES-256-GCM envelope encryption, keyed per customer. They're used only to mint short-lived access tokens, which live in memory for the duration of a single API call and are never persisted. Revoking from your Account page severs the grant at Amazon's side immediately.
Encryption in transit
TLS 1.3 everywhere. HSTS enabled. No insecure fallbacks.
PII handling
Skills are scoped so buyer PII is never requested from Amazon in the first place. If an SP-API endpoint required for a business skill returns incidental PII, the connector drops those fields before returning the response.
Model training
Your data is not used to train models — ours or anyone else's. Claude processes questions in-session.
Disclosure
Security issues: security@lumitec.ai. We respond within one working day. Coordinated disclosure welcome.
Sub-processors
Listed in full on the sub-processors page. Updated at least 30 days before any change.