Robnu acts on your behalf with marketplaces. Every order pull, every confirmation upload, every manifest submission goes through credentials that, if compromised, could let an attacker do significant damage. So we treat marketplace tokens with the same architecture a payments processor would treat card data. Here’s the model.
What we store, and what we don’t
We store: marketplace session tokens and refresh tokens. We never store: your marketplace password.
The Chrome extension performs the OAuth-style handshake against the marketplace inside your browser session. Your password never leaves your machine. The handshake produces a session token, the extension hands that token to Robnu, and Robnu stores the encrypted token in the vault.
This means a hypothetical breach of Robnu cannot leak your marketplace password — because we don’t have your password.
Per-seller DEK
Each seller gets their own Data Encryption Key (DEK) — a 256-bit AES key, generated when you sign up.
The DEK encrypts your tokens. Different sellers’ tokens are encrypted with different DEKs. This bounds the blast radius: if a DEK is compromised somehow, it compromises one seller’s tokens, not all of them.
KMS-sealed
The DEK itself is sealed under a master key held in AWS KMS. KMS is hardware-backed key management — the master key never leaves the HSM, never sits in our application memory, and every operation against it is logged in CloudTrail.
To decrypt a token, Robnu has to:
- Read the encrypted DEK from the database
- Send it to KMS to be unsealed
- Use the unsealed DEK in memory to decrypt the token
- Use the token, then drop the unsealed DEK from memory
Step 2 is the choke point. KMS authenticates the request, checks the access policy, and logs the operation. An attacker who has the database alone but not KMS access cannot perform step 2 — the encrypted DEK is meaningless without KMS.
The audit trail
Every decrypt is logged. Sellers can see their own audit trail (when their tokens were read, by which Robnu service, against which marketplace). Auditors see the org-level trail.
For sellers who care about compliance posture (DPDP, future SOC 2): this is the gold-standard primitive for credential storage. The audit trail is also where suspicious access patterns get caught — if a service starts decrypting tokens 100x more than usual, the alert fires before anything operational breaks.
Rotation
Refresh tokens rotate on every use. Session tokens rotate on schedule (typically 15-min TTL). DEKs rotate on suspicion or on a 90-day schedule.
Rotation is cheap because the architecture is per-seller. Rotating one seller’s DEK doesn’t touch any other seller. Rotating a session token doesn’t touch the refresh token.
What this protects against
- Database leak alone. Without KMS access, the leaked rows are encrypted blobs. Useless to the attacker.
- Application memory dump. The unsealed DEK lives in memory only briefly during a decrypt. Memory-only attacks have a small window.
- Insider threat. KMS logs everyone — including engineers. A malicious insider would need to decrypt many tokens to do damage, and the audit trail would catch it.
The vault protects what we can protect. It’s not a panacea.
Read more
- Security — full architecture overview
- The extension — how the Chrome extension does the handshake
- The agentic OMS — what Robnu does once the tokens are safely stored