Securitybastro.ai/security

Built as if the audit is tomorrow.

What you upload to Bastro is a customer list — an asset your business runs on. This page states exactly how it is handled: encrypted in both directions, walled off per account, retained on your terms.

TLS 1.2+

In transitEvery connection

AES-256

At restUploads and reports

Service keys in the browserServer-side only

Data handlingEncryption · isolation

Encrypted both ways, isolated by row.

In transit: Every connection encrypted with TLS 1.2 or higher — uploads, downloads, API calls.; TLS 1.2+
At rest: Uploaded lists and result files encrypted with AES-256.; AES-256
Account boundary: Postgres row-level security on customer tables — your jobs, lists, orders, and wallet are readable by your account and no other.; RLS
Service credentials: Service-role and vendor API keys live in server-side configuration only. They are never shipped to the browser and never stored in the database.; Server-only

Row-level security is the boundary, not a convention: server code queries through the same policy layer, so an application bug cannot casually cross accounts.

Access controlsThree roles

Three roles. No public back door.

Customer

Reads and writes only its own rows: scrub jobs, orders, wallet.

Staff

Invite-only. No public staff signup exists. Operational consoles: vendors, inventory, orders.

Admin

The only role that can change roles. Vendor spend and margin data stop at staff and admin.

RetentionPolicy, stated

Retention is a policy you can point to, not a default you discover.

Scrub verdicts are only useful if you can produce them later. So job files are retained for your audit trail — and deletion is yours, not a support ticket.

Job files: Inputs, clean files, and flagged files are retained so your audit trail stays intact — a verdict you can produce months later. Delete a job and its files whenever you choose.
Verdicts: Stored with the job they belong to, as that job’s record. Never resold, never reused across jobs or customers.

Posturesecurity@bastro.ai

No borrowed badges.

Bastro does not hold SOC 2 or ISO 27001 certification today, and you will not find a badge here implying otherwise. What we claim is what this page describes: audit-grade practices — per-account isolation enforced in the database, an append-only credit ledger, evidence stored with every job — stated plainly so you can verify them against your own checklist.

Responsible disclosure

Found a vulnerability? Report it to security@bastro.ai. Include reproduction steps; we read every report and will acknowledge yours. Good-faith research is welcome — we ask only that you avoid accessing data that is not yours and give us time to fix before publishing.

Encrypted both ways, isolated by row.

In transit

Every connection encrypted with TLS 1.2 or higher — uploads, downloads, API calls.

TLS 1.2+

At rest

Uploaded lists and result files encrypted with AES-256.

AES-256

Account boundary

Postgres row-level security on customer tables — your jobs, lists, orders, and wallet are readable by your account and no other.

RLS

Service credentials

Service-role and vendor API keys live in server-side configuration only. They are never shipped to the browser and never stored in the database.

Server-only

Row-level security is the boundary, not a convention: server code queries through the same policy layer, so an application bug cannot casually cross accounts.

Retention is a policy you can point to, not a default you discover.

Scrub verdicts are only useful if you can produce them later. So job files are retained for your audit trail — and deletion is yours, not a support ticket.

Job files

Inputs, clean files, and flagged files are retained so your audit trail stays intact — a verdict you can produce months later. Delete a job and its files whenever you choose.

Verdicts

Stored with the job they belong to, as that job’s record. Never resold, never reused across jobs or customers.

No borrowed badges.