How AgentXray keeps one seller's data from another
AgentXray reads a seller's own Amazon settlement data, so the question that matters is not whether we promise to keep accounts apart, but whether the system can mix them up at all. What follows is what we enforce, how it is enforced, and — at the bottom — the two things we do not claim.
Buyer PII never arrives
AgentXray holds no Amazon PII role. Customer names and shipping addresses are not sent to us, so there is no store of them to protect, leak or subpoena. Automatic buyer-data fetching is disabled in configuration as a second stop. This is a smaller claim than logging access to that data, and a stronger one.
Isolation is a database rule, not a query filter
Row-level security is enabled on the tables that hold seller data, and the role the request path connects as cannot bypass it. A session that has not declared whose data it is reads nothing — not everyone's. The failure mode of forgetting the scope is an empty screen, which is the direction a mistake should fail in.
Background sync jobs run as a separate role that does walk every connected account, because a settlement poller that could only see one seller would be broken rather than safe. Those jobs serve no HTTP request and are scoped by the credential they were handed.
On 2026-08-29 we ran a live cross-account attempt against the running system rather than a test double. Reads returned nothing across the boundary and the write path could not cross it.
The drafting token cannot approve
An assistant connected over MCP can file a draft — a bid, a budget, a negative keyword, a listing edit. It cannot approve one. The credential it holds is refused with a 401 at the approval endpoint, so the gate does not depend on the assistant behaving well, or on a prompt it might be persuaded to ignore.
Least privilege
The application's database role is not a superuser, cannot create or alter tables, and holds no rights beyond reading and writing the rows it serves. Schema changes run under a separate credential used only by migrations.
What we do not claim
Two things a security page is expected to list, which we cannot honestly list:
- No third-party penetration test. We have not commissioned one. Its absence is the stated reason Amazon declined our application for the PII role — which is also why buyer data never arrives, above.
- No encryption-at-rest attestation. We requested written confirmation from the hosting provider and have not received it. Until we do, we will not put a cipher name on this page.
Both are listed because a security page carrying only strengths tells a reader nothing about which of them to believe.