The questions a security or procurement review asks — encryption, isolation, data handling, sub-processors — answered here so you don’t have to send a spreadsheet. Every claim is grounded in how the product actually works, and where we have a limit, we say so.
Encryption, credentials, and payments.
Everything between you and us travels over HTTPS/TLS. Plain HTTP is redirected to HTTPS. The connection from our application to the database is TLS-enforced at the database server — it refuses unencrypted connections, with a TLS 1.2 floor.
Your data sits on Azure Database for PostgreSQL with storage encryption (AES-256, Microsoft-managed keys) and encrypted backups. This protects the disks and backup media. It is not zero-knowledge — see the limits below.
Passwords are stored only as bcrypt hashes (never the password itself). API tokens are stored only as SHA-256 digests — the token is shown once and never again. Two-factor (TOTP) seeds are encrypted at rest (AES-256-GCM). A database leak yields no usable password, token, or 2FA seed.
Billing runs entirely on Stripe's hosted checkout and billing portal. Card numbers go straight to Stripe — they never reach our servers or database. We store only Stripe's object IDs.
Your library is yours; nothing crosses accounts by accident.
What you create belongs to you, your team, and your company. Another customer — including one who signs up and pays — cannot see, search, or reach your content. Access to a library comes from your membership in it, and every read is checked against that membership.
Isolation isn't just asserted. An adversarial test stages a paying stranger with no relationship to your org and confirms they reach nothing — your content, titles, who's editing, references, all denied — and it runs on every single deploy before anything ships.
Two things, both deliberate and both visible to you: the prebuilt example library we publish (our content, read-only, everyone can browse it), and a share link you choose to create (public, read-only, expires in 7 days, revocable).
We don't sell your data, mine it, or use it to train anything. There's no AI inside AIStorageDepot at all — when you “Open in Claude,” your own browser carries the prompt to your own AI account. The only AI that sees your prompts is the one you send them to.
Retention, backups, portability, and access controls.
Delete an item and it sits in Trash for 30 days, then is removable permanently (or you can delete it forever immediately). You can delete your whole account yourself from Settings — no support ticket. We don't purge accounts for inactivity.
Automated backups with 35-day retention; we've run and passed a restore drill. Every item also keeps full version history, so an overzealous edit is one click from undone.
Download any item as a clean file, export a .zip, or pull everything over the API and MCP. A company owner can export every library in the organization as one foldered .zip. No lock-in.
Optional two-factor auth, three-strike lockout on failed sign-ins, per-account session list with sign-out-everywhere, new-device login alerts, and — for organizations — role-based access, an admin audit log of administrative changes, and optional VPN/IP allowlisting.
The limits, plainly. At-rest encryption protects disks and backups; it is not zero-knowledge, so your content is readable to us. Isolation between accounts is enforced by our application and its tests, not by a wall inside the database (no row-level security). We hold no SOC 2 or ISO 27001, have not commissioned a third-party penetration test, and don’t yet offer SSO. If any of that blocks your evaluation, tell us — we’d rather hear it than have you assume.
Is data encrypted in transit and at rest?
Yes — TLS in transit (HTTP redirects to HTTPS; the app→database link is TLS-enforced server-side, TLS 1.2 floor) and AES-256 at rest via Azure with Microsoft-managed keys, including backups.
Is it zero-knowledge / end-to-end encrypted?
No. Prompt content is stored so we can search and serve it, which means our operators can technically read it — the same trade any service that searches your content makes. If you need content we cannot read, don't store it here.
How is one customer isolated from another?
In the application layer: every read derives its scope from your account's memberships and is checked against them, and this is covered by an adversarial isolation test that runs on every deploy. It is not enforced by database row-level security, so the guarantee is our code and those tests.
How are passwords and API keys stored?
Passwords as bcrypt hashes; API tokens as SHA-256 digests (shown once); 2FA seeds encrypted at rest (AES-256-GCM). None are recoverable from a database dump.
Do you use our data to train AI models?
Never. We don't train on, sell, or mine your content, and no model runs on our servers at all.
Do you have SOC 2 / ISO 27001 / a penetration test?
No — we're candid about this. We're a small operation and hold none of these today. If a formal attestation is a hard requirement for your team, tell us and we'll be straight about where we are.
Do you support SSO / SAML?
Not yet. Sign-in is email + password with optional two-factor. SSO is on the roadmap; if you need it to move forward, let us know — it helps us prioritize.
Who are your sub-processors?
Listed on our sub-processors page: Azure, Stripe, Resend, Cloudflare.
How do we delete our data?
Delete items (30-day Trash, then permanent) or your entire account, yourself, from Settings — no ticket required. Export everything first if you like.
Can we get a signed DPA?
Reach out via Contact. We'll work through a data-processing agreement with you.
Need something not covered here? Contact us — we answer security questions directly. See also the security overview.