Where Firesell is today#

Security pages are usually written in a confident present tense about systems that already run at scale. Firesell is earlier than that, so the first thing this page does is say where it actually is.

Pre-launch. Features may change, and the terms describe the service that way.
Amazon only, until v1. Firesell works with the Amazon Selling Partner API and no other sales channel. The data model is channel-keyed because that is cheap now and expensive to retrofit; it is not a claim that a second channel exists.
Connecting is a manual pilot bridge. You supply credentials for an SP-API application that is already registered and already authorized against your selling account. There is no one-click Amazon authorization and no OAuth flow in Firesell today. A Firesell public application is planned and unscheduled; when it arrives it becomes a new credential version rather than a migration you have to perform.
Live credentials are gated. Before Firesell accepts a real seller credential, every check in the pre-acceptance list has to pass and an Amazon-permitted authorization route has to be confirmed.

We would rather be early and precise than sound established. If a sentence here stops being true, the page changes in the same release as the thing that changed it.

How to read this page#

A list of security commitments with nothing to distinguish them reads as a list of promises. Every commitment below carries a grade, and states what would have to become true for it to fail.

ArchitectureIt cannot happen, because of how the system is built. Breaking it takes a deliberate change to a permission boundary, not a mistake in application code.
Verified by testA test fails if it stops being true. The test is the guarantee; a deleted test is a broken commitment.
PolicyA decision a person could reverse. We intend to keep it, and nothing in the system stops us changing our mind. Policy is the weakest grade on this page and we are not going to dress it up as one of the other two.

The honest limit. No storage design protects a secret from a workload that is authorized to retrieve it. A compromised worker, at the moment it legitimately decrypts your credential to call Amazon, has your credential. Everything below bounds the blast radius; it does not eliminate the authorized-consumer case, and we are not going to pretend otherwise.

What we are protecting#

One asset dominates: a long-lived refresh token that grants continuing access to your Amazon business. Everything else Firesell holds — listings, offers, orders, financial records — is a copy of data Amazon also has. The token is not. Here is what we think can go wrong, and what the design does about each.

Attack paths, and the control that bounds each one.
Path	Consequence without the control	What we do
Our database read path is compromised	Plaintext credentials for every organization	Ciphertext only. Decryption needs a separate AWS identity the database has no access to
Our web deployment is compromised	Read access to the credential store	The web tier can encrypt and cannot decrypt. It cannot read any credential, including one it sealed itself
A background worker is compromised	Plaintext for the credentials it decrypts	Unavoidable for an authorized consumer. Bounded by least-privilege scope, encryption context, and an audit record of every decryption
One organization references another's connection	Your credential used on someone else's behalf	Encryption context binds ciphertext to the organization and connection; database policies and composite foreign keys stop the reference existing at all
A database backup is stolen	Offline recovery of every credential	Ciphertext is useless without the key management service, which is not in the backup
Credentials leak through logging	Exposure through our own observability	Redaction is a tested contract covering logs, traces, error bodies and idempotency receipts

Connecting, replacing, disconnecting#

What we ask for

A connection label, your seller ID, the SP-API region your account is in, and the credentials for an SP-API application already authorized against your selling account: the Login with Amazon client ID and client secret, and the matching refresh token. The form will not accept a short-lived access token in place of a refresh token.

What we never ask for

Your Amazon account password. We do not sign in as you, ever.
An AWS access key or secret key. The Selling Partner API stopped requiring request signing in 2023, so there is nothing for them to do.
An IAM role ARN.

The commitments

Architecture
We read only what the roles you granted cover. Amazon, not Firesell, decides what an authorization returns, so a role you have not granted is not one we can reach around.
Fails if you granted a broader role than you meant to. You can review and change what you granted in Seller Central at any time, without asking us.
Architecture
Secret fields are write-only. A saved connection shows that a credential is present and when it was last updated, never its value. No screen, export, support tool or administrator role can display a stored credential, to you or to us. A credential is replaced, never revealed.
Fails if a reveal interface were built. It cannot be built in the web application, because that tier has no key to decrypt with — see who can decrypt.
Architecture
Credential material travels only in the body of an authenticated HTTPS request. Never in a URL, a query string, an analytics payload, session replay, error telemetry or browser storage. Secret fields are cleared after submission, on navigation, on session expiry, and when the active organization changes.
Fails if secrets were accepted anywhere other than an authenticated request body — a change to the connection form, visible to you the first time it happened.
Architecture
Only an organization administrator can add, test, replace or disconnect credentials, and that membership and role are re-checked immediately before every credential operation — including just before a result returned by Amazon is activated. Other members see that a connection exists and whether it works; they do not see its inputs.
Fails if the membership check before a credential operation were removed or allowed to assume authorization when the identity provider is unreachable.
Verified by test
A replacement is verified while the previous version is still live, so a failed replacement never takes away working access. Replacement and disconnect both beat a slow verification that lands late. Disconnect disables use immediately, then deletes every active and candidate version through a cleanup that is retried until it completes and stays visible to us while it is pending. Queued work that has not yet run cannot obtain a credential afterwards.
Fails if the version ordering were relaxed, or the disconnect path stopped winning against an in-flight verification. Both cases are covered in the pre-acceptance list.

You can also withdraw the authorization at Amazon, independently of us. We would rather you have two ways to cut us off than one.

How a credential is stored#

Envelope encryption against a customer-managed key in AWS Key Management Service, in this order:

A verified organization administrator submits the credential over an authenticated HTTPS request.
Our web tier asks KMS for a data key, encrypts the material with it, and discards the plaintext data key.
The ciphertext, the wrapped data key, a backend identifier and a version number are written to a private database schema with no exposed API surface and no client grants.
A worker that needs the credential asks KMS to decrypt, supplying the identical encryption context.

Architecture
The encryption context is the organization, the connection and the credential version. KMS decrypts only when that context matches exactly, so a ciphertext row copied into another organization, pointed at another connection, or replayed against an older version simply does not decrypt. Tenant separation here is a property of the ciphertext, not only a database rule.
Fails if the encryption context stopped binding organization, connection and version — which would require changing both the key usage and the storage code, and would be caught by the copy-between-organizations check in the pre-acceptance list.
Architecture
A stolen database backup yields ciphertext and nothing else. The key is not in the backup.
Fails if a backup were taken of the key material itself, which is held by KMS and never leaves it.

If the metadata write fails after the secret is stored, the connection enters a recoverable pending state with a retryable cleanup that we can see. It does not become an orphaned secret nobody knows about.

Who can decrypt it, and who cannot#

This is the single most important control on the page, and the one we would not weaken for convenience.

Key management permissions, by identity.
Identity	Key permissions	Why
The web tier	Encrypt and generate a data key. Never decrypt	Envelope encryption genuinely needs to generate a data key. Reading one back is a different permission, and the web tier does not have it
Background workers	Decrypt	The only consumer, at the moment of a call to Amazon
Key administrator	Key policy management, no data operations	Separation of duties: whoever manages the key cannot use it on data
Everything else, including every database role	None	There is no other legitimate consumer

Architecture
The web tier can seal a credential and cannot open one — not even one it sealed itself. Only background workers decrypt, at the moment of a call to Amazon. Every key management operation is recorded in an AWS CloudTrail audit log.
Fails if someone added the decrypt permission to the web tier’s access policy. A negative test asserts that the attempt is refused, so the change would have to be made deliberately and the test deleted with it.

Two things follow that you can check us on. There is no “test my saved credential” button in the web application, because the web application could not perform the test — verification is worker work. And the person who administers the key has no permission to use it on data.

Why a credential never reaches a log#

Most credential leaks are not break-ins. They are a secret printed into an error, a trace, a retry record or a support ticket. Firesell runs its background work on Temporal Cloud, which persists the history of every operation in a third party’s store — so we treat that history as a storage boundary, not a logging preference.

Verified by test
Credential material never appears in a workflow or activity argument or result, nor in a failure, heartbeat, memo or search attribute — all of which are persisted in workflow history. Nor in application logs, traces, error bodies, or the receipts we keep to make a retried request idempotent. Nor in an audit record: audit events say what happened, never what the secret was. Sealed ciphertext is treated the same as plaintext and does not travel through those channels either.
Fails if the redacting failure converter or the payload codec were removed. Both are build-time requirements, and the pre-acceptance list inspects logs, traces, error bodies and idempotency receipts after a deliberately failed submission.

Queued work carries a connection identifier and nothing else. A worker starts from that identifier and re-resolves what it is allowed to do from the database at the moment it executes, which is why a removed administrator’s already-queued operation can be refused rather than running on a stale permission.

Keeping one organization out of another#

Layered deliberately, so no single mechanism is load-bearing on its own and an application bug is not enough to cross the line.

Isolation layers, from the session inward.
Layer	Control
Session	The sign-in token is verified for issuer, audience, subject and organization context
Route	Every organization-scoped request carries an explicit organization identifier, compared against the token
Service	A fresh membership and role check for administrative changes. If we cannot confirm it, the answer is unavailable — never an assumption that you are allowed
Database	Row-level security on every tenant table, covering rows produced by inserts and updates as well as reads
Referential	Composite foreign keys, so a child row cannot point at another organization's parent
Cryptographic	Encryption context binding each ciphertext to its organization and connection

Architecture
Background workers connect through a restricted database role — never a blanket service key — and set the active organization as a transaction-local value derived on the server from the connection being worked on, never from whatever a workflow was handed. The worker’s own row-level security requires that value to be present, valid and matching. If it is absent, the query is denied rather than defaulting to everything.
Fails if a worker were given the blanket service key instead of its restricted role, or row-level security were dropped from a tenant table.
Architecture
Bulk data files in object storage carry an organization and connection prefix in their key, enforced by an access-policy condition rather than by convention.
Fails if the access-policy condition on the storage prefix were removed.

Writing to Amazon#

Reading your account is one kind of trust. Changing it is another, and it is the one sellers are right to worry about.

Architecture
A bulk or destructive change becomes a plan you read before anything is submitted. Your approval is bound cryptographically to you as the approver and to a hash of the exact content you approved, and it is verified again by the worker before submission. If the plan changes after you approve it, the hash no longer matches and the write does not run.
Fails if approval became a plain flag on a row, or the worker stopped checking the hash before submitting.
Architecture
An operation you ask for is recorded durably before it is acknowledged. If we cannot record it, the action is refused outright — we never tell you something is queued when it is not.
Fails if an acknowledgement were sent before the durable record of it existed.
Verified by test
Failures are reported in honest categories. A timeout is not invalid credentials — it means the outcome is unknown, and we say so rather than inviting a retry that could apply a change twice. A missing permission is not a revocation: one means a role you have not granted, the other means you withdrew access, and they have different fixes. A partly failed batch says which rows landed.
Fails if a provider error were surfaced raw or mapped to a category we cannot actually distinguish. The timeout case is covered in the pre-acceptance list.
Policy
Every call to Amazon goes through a registered Selling Partner API application. We use no browser automation and we do not scrape Seller Central. Agent and AI surfaces stay switched off until we have read the governing agreement text ourselves rather than a summary of it.
Fails if we changed our minds. Nothing in the system prevents it; it is a standing rule, and scraping would also breach Amazon’s terms.

Data protection, location and providers#

Policy
The site and the application are served over HTTPS. Data is encrypted at rest with AES-256 — KMS envelope encryption for credentials, and provider-managed encryption at rest for the database and object storage.
Fails if a store were provisioned without encryption at rest. Credentials are the exception: their encryption is architectural rather than a provider setting.
Policy
We do not request the Amazon roles that grant buyer personal information, so buyer names, shipping addresses, phone numbers and email addresses are never retrieved.
Fails if a feature needed buyer data. If one ever does, we will request the role, update the privacy policy, and tell you before the feature is switched on.
Policy
Application secrets live in the encrypted configuration stores of our hosting providers, never in source code or a repository.
Fails if a secret were committed to the repository by mistake.

These are the providers that process data on our instructions. The list is part of the system, not a footnote to it: when a provider is added, removed or changed, this table changes in the same release.

Infrastructure providers. All store data in the United States.
Provider	Purpose	What it holds
Vercel Inc.	Application hosting and content delivery for the Firesell web application.	Application traffic; no seller credentials are readable by this tier.
Supabase, Inc.	Managed PostgreSQL database, hosted on Amazon Web Services.	Seller account records, catalogue, inventory, pricing and order data, and encrypted credential ciphertext.
Amazon Web Services, Inc.	Key management, background processing, object storage and message queues.	Encryption keys, queued work, and bulk data files.
Temporal Technologies, Inc. (Temporal Cloud)	Durable orchestration of background operations such as imports and updates.	Operation metadata and identifiers. Credential material is excluded by a redaction layer.
Clerk, Inc.	User authentication, organizations and team membership.	Your name, email address and organization membership. No Amazon Information.

Retention and deletion#

Disconnecting an Amazon account disables the stored authorization immediately and deletes every version of it.
Closing your account deletes your Amazon Information within 30 days. Copies in encrypted backups go as those backups expire on their retention cycle.
If we ever hold personal information originating from Amazon, it is deleted within 30 days of delivery, as Amazon’s Data Protection Policy requires.

Full detail, including what we keep for tax and security reasons, is in the privacy policy.

Vulnerability reports and incidents#

Found something? Tell us.

Write to security@firesell.app. Every message reaches a person, and we answer each one.

Policy
We will not pursue legal action over security research carried out in good faith: test only against your own account, do not access anyone else’s data, and give us a reasonable chance to fix what you find.
Fails if research went beyond it — accessing another seller’s data, or publishing before we have had a reasonable chance to fix what you found.
Policy
Where an incident involves Amazon Information, Amazon’s Data Protection Policy requires notification to security@amazon.com within 24 hours of detection, and we notify affected customers without undue delay.
Fails if nobody noticed in time. This is the weakest kind of commitment on the page and we are labelling it as such: a notification deadline is met by a person acting, not by a permission boundary.

Worth naming the difference: the controls in the sections above are architectural — they hold because of how the system is built. This section is procedural. It holds because a person does it, and we would rather you knew which kind of promise you were reading.

What we do not claim#

A security page is shaped like a list of controls, which makes it very easy to write controls that do not exist. Here is what this one is not saying.

No SOC 2, no ISO 27001, no third-party penetration test, no audit. None of these has happened. If one does, it will be named here with its date and scope.
No security team, no access-review programme, no background checks, no formal incident-response roster. Firesell is built and operated by a very small team. Claiming an organizational security function we do not have would be the easiest sentence on this page to write and the least true, which is why the commitments above are architectural rather than procedural.
No response-time guarantee. We answer every message that reaches us, and we do not publish a target we are not measuring.
No uptime figure and no availability guarantee. Nothing is measured yet and nothing is contractual.
No endorsement by Amazon. Firesell integrates with the public Selling Partner API. It is not approved, certified, sponsored or partnered by Amazon.com, Inc., and we do not use Amazon’s marks as a badge.
No “bank-level” or “military-grade” anything. Those phrases mean nothing. The specific claims above are meant to be checkable instead.

If you need an assurance this page does not give — a questionnaire answered, a contractual commitment, a review of the design — ask. We would rather have the conversation than publish an adjective.

Checks before a live credential#

These are tests, not intentions. Each has to pass before a real seller credential is accepted. We publish the list because a security claim you can check beats one you have to believe.

The pre-acceptance check list.
Check	Required result
Another organization submits a known connection identifier to trigger credential use	Rejected as not found, with nothing disclosed
An ordinary authenticated database client reads the credential table	Denied by grants, not only by row-level security
The web tier attempts to decrypt	Denied by access policy
A ciphertext row is copied between organizations and decrypted	Fails on encryption context mismatch
A removed administrator's queued operation reaches a worker	Authorization re-resolved and the operation refused
A credential replacement races an in-flight verification	The newer version wins; working access is never lost
A disconnect races queued work	The queued work cannot obtain credentials
The secret saves but the metadata write fails	A recoverable pending state with retryable cleanup, visible to us
A backup is restored containing a disconnected connection	The connection stays disconnected and unusable
Logs, traces, error bodies and idempotency receipts are inspected after a failed submission	No credential material present anywhere
Amazon times out during verification	Recorded as provider unavailable, never as invalid credentials

Contact#

Firesell is a product of Maikhana LLC, a limited liability company formed in Texas, United States. Every address below reaches a person.

Security reports and questions: security@firesell.app
Privacy and data requests: privacy@firesell.app
Everything else: support@firesell.app

Maikhana LLC, Texas, United States. Related documents: privacy policy · terms of service.