Built to investigate your listings, not to monetize your information.

Every record that belongs to a workspace carries that workspace’s identifier, and the database enforces access to it directly. Row level security is enabled and forced on every table holding customer or marketplace-derived data, and the default is denial — a table without an explicit policy grants nothing.

Relationships between records are keyed on the workspace as well as the parent record. That is a deliberate choice: row level security alone cannot stop a row from pointing at another tenant’s object, so the constraint that would allow it does not exist in the schema. A test suite asserts this property and fails the build if a new table is added without it.

Marketplace credentials are handled only on the server. They are never sent to a browser, never included in a client bundle, and never written to logs — not even in redacted form.

Three independent mechanisms enforce this rather than one: the modules that read privileged configuration cannot be imported into client code without failing the build, a lint rule forbids the import path, and an automated check scans the compiled output for credential material and fails if any is found.

All traffic to ASINmd is served over TLS. Data at rest is held in a managed Postgres service with storage-level encryption provided by the platform.

Sensitive credentials are additionally kept outside browser clients and handled through server-side application boundaries, as described above.

We do not claim any encryption capability beyond what our infrastructure providers actually deliver today.

Access inside a workspace is role-aware: permissions are checked per capability rather than by comparing role names, so a new capability cannot accidentally inherit administrative reach.

Operational access to ASINmd itself is a separate boundary entirely. It is not derived from any customer role, and not from any value a user can edit about their own account. It requires membership of a server-side operator list, a verified second authentication factor in the session, and a credential rotated within the last year. Any one of those failing closes the door.

A diagnostic product that quietly reports stale data as healthy is worse than one that reports nothing. ASINmd treats freshness as evidence in its own right: a stored conclusion cannot age into a false reassurance, so trust in monitoring data is re-derived when it is read rather than recorded once and repeated.

Where data cannot be retrieved or its age cannot be established, the product is built to say so and withhold the conclusion, rather than present a confident state it cannot support.

ASINmd investigates listings. Doing that does not require customer addresses, order details, buyer names or buyer messages, so the product is architected not to ingest them. This is a recorded engineering decision enforced in our own development rules, not an aspiration.

The practical consequence is that a category of data we never hold cannot be exposed by any defect in our software, any misconfiguration, or any compromise of our systems.

There are none. ASINmd runs no analytics, advertising or session-recording service, and marketplace-derived data is never sent to a third party for measurement. The public pages of this site load no third-party scripts at all.

Data from one workspace is not combined with another’s. There is no cross-seller benchmark, no shared intelligence store, and no model trained on marketplace-derived data from multiple customers. Historical context is used only within the workspace that produced it.

If you believe you have found a security issue, please contact us and choose “Security & privacy”. Please include enough detail to reproduce the issue. We will acknowledge your report and keep you informed while we investigate.