Trust and security

Your data is yours. Here is the standard we will prove before your store connects.

StoreRounds is recruiting its first external pilot chains. The connector and phone-capture paths work with test-store data, but no named POS adapter is generally available and no real non-canary chain is connected today. This page separates the controls already proven in the prototype from the controls that must pass store-specific verification before a pilot connection.

Last updated 2026-07-15 · storerounds.com/security

Where the product stands, said plainly

StoreRounds today is a working product prototype, not a generally available connector service. We are accepting applications for the first external pilots. Before any store connects, its exact adapter must prove read-only access, minimized output, safe revocation, and agreement with that store's own close report. The formal privacy and data-processing paper behind these commitments is with counsel now; until that review completes, we will not accept payment.

한국어 요약

현재 StoreRounds는 테스트 데이터로 검증한 프로토타입이며, 실제 매장용 POS 커넥터는 아직 일반적으로 제공되지 않습니다. 아래 내용은 첫 파일럿 연결이 반드시 따라야 할 보안 기준입니다. 커넥터는 지정된 테이블만 읽기 전용으로 읽고, 나가는 방향으로만 TLS 통신하도록 설계되었습니다. 실제 매장을 연결하기 전에는 해당 어댑터가 매장 자체 마감 보고서와 일치하는 읽기 검증을 통과해야 합니다. 데이터는 팔지 않으며, 고객의 명시적 동의 없이 공유 모델 학습에 사용하지 않습니다.

이 한국어 요약은 이해를 돕기 위한 안내이며, 기준이 되는 전체 내용은 위 영문 페이지입니다. 정식 개인정보 · 데이터 처리 문서는 현재 변호사 검토 중입니다. 한국어로 궁금하신 점은 [email protected]으로 편하게 문의해 주세요.

Three promises

Yours to keep, export, and delete. Until self-serve controls ship, send an export or deletion request from your account email to [email protected]. We will confirm the request's scope and completion timeline. You can revoke connector access at the store by removing its read-only credential.
Never sold. Not to anyone, not at any price. No data brokers, no advertisers, no competitors. Our intended business model is paid software, not data resale. The signed Data Processing Addendum that will write this into a customer contract is with counsel; we will not accept payment before it is ready.
Never trains a shared model without your consent. A future chain memory would be isolated to that account. The cross-chain StoreRounds Index is not active; if built, it will require explicit, written, revocable owner consent and remain off by default.

What a pilot connector may read, and what must stay in your store

The prototype is designed to read a narrow, named set of sales and store tables and aggregate the day's totals on the store machine before anything is sent. Each pilot adapter must prove this boundary against that store's schema and close report before real data moves.

Allowed read set for a pilot

Daily sales header: date, store, totals, transaction count.
Sales lines, for category and product-level totals.
Tender split: cash versus card totals, for reconciliation.
Store codes and names, to label each location.

Outside the allowed read set

Payment card numbers, PAN, or track data. Never read, at all.
Any table the read-only user was not explicitly granted.
Employee records and customer personal data.
A full export of your database. Only aggregated totals go out.

The connector security model

The current connector package is an unsigned prototype, so Windows may show an unknown-publisher warning. Code signing is a paid-launch gate. In the test-data flow, the connector runs on the back-office computer, signs in as a read-only user, aggregates only the named stores, and sends the minimized result over one encrypted connection. It is not designed as a remote-access tool, and a pilot will not grant StoreRounds a session on the machine.

It can

Run SELECT queries against the named table groups only.
Open one outbound TLS connection to a single StoreRounds host on 443.
Aggregate the day's totals locally and send those totals out.
Report its own health and log every poll and send as receipts.

It cannot

Insert, update, delete, or alter any row or object. Writes are denied at the database.
Accept any inbound connection. It opens and listens on no port.
Give anyone at StoreRounds a shell, RDP, or interactive session.
Move laterally. One read-only credential, one database, no domain rights.

A printable one-page version of this model, with the exact grants and audit queries for your IT person, ships with onboarding.

The capture path, and the bank and personal data it handles

The prototype also has a tested capture path for photographed deposit slips, check deposits, and invoices. No real non-canary chain uses it today. If enabled for a pilot, this path can handle bank account numbers, routing numbers, and names, the exact class of data the connector is designed not to read, so it must meet the stricter rules below before customer use.

Every upload is validated at the server: real image type checked by content, size limited, image re-encoded, EXIF and location data stripped, SVG refused.
Stored encrypted at rest under keys scoped to your chain, with retention limited to the reconciliation window, not kept forever.
Attribution is by login, never by face or fingerprint. No biometric is read from a photo.
An OCR amount is a draft a person confirms, never a number acted on unseen, and text inside a photo is data to reconcile, never a command the software obeys.
A mismatch names data to look into, never a person at fault.

Why VERIFIED waits for the bank: matching a slip photo to the point-of-sale is not the same as confirming the deposit cleared the bank. If capture is enabled for a pilot before the roadmap's bank-settlement feed exists, a slip-only reconciliation must stay provisional and must never be stamped VERIFIED on the strength of a photograph alone.

Least privilege, from the API to the intended role model

The production owner API already enforces tenant and owner boundaries. The wider pilot role model below is the access contract we intend to verify before those roles are enabled with customer data.

The owner would see every store and the money, and would be the only role able to grant money visibility to anyone else.
A regional or HQ manager would see a defined set of stores, with no financials unless the owner explicitly enables them.
A store manager would see their store only, complete assigned rounds, and submit receipts.
Staff and cashiers would get no dashboard and no standing access; a task would reach them as a single scoped link.

The intended pilot contract is that every grant, revocation, and sensitive view lands in an audit trail. A task should close with proof the work is done and the number is right, not a log of who was watched. Receipts, never surveillance.

Don't take our word for it. Audit it, and revoke it.

Audit a pilot: list every permission the storerounds_ro login holds and expect only SELECT on the named tables. Watch the connector's single outbound destination at your firewall. Review its sessions in your normal database views. The prototype writes a local connector event log; a live mirror in the owner's dashboard is not yet a published capability.

Revoke, immediately, as your own action: drop the read-only user, or remove the connector. Either one is enough on its own.

-- SQL Server
USE [<YOUR_POS_DB>]; DROP USER [storerounds_ro];
USE [master];        DROP LOGIN [storerounds_ro];

-- MySQL / MariaDB
DROP USER 'storerounds_ro'@'10.0.0.%'; FLUSH PRIVILEGES;

A pilot is allowed to proceed only after these checks prove the connector has no write grant on the store's POS database.

Subprocessors

Current infrastructure vendors are Cloudflare (site hosting, cookieless Web Analytics, and prototype object storage), Railway (prototype application hosting), Neon (prototype database hosting), Resend (prototype transactional email), and Kit (pilot-application emails). No payment processor receives data today. Before a customer connects a store, this list will state exactly which vendors can touch that pilot's data.

What exists now, and what is on the roadmap

We would rather tell you what we have not built than let you assume we have. The same rule the product runs on: say what is not ready at the same volume as what is.

Proven in the prototype

TLS 1.2 or higher in transit, encryption at rest.
Read-only, least-privilege database access to named tables.
Outbound-only connection, no inbound ports opened.
Credential held in the machine's protected credential store.
Audit trail on access, plus a local connector event log.
Server-enforced tenant and role boundaries on the production owner API, with cross-tenant release tests.
Per-user least-privilege roles, money-visibility gated to the owner.

On the roadmap

Production connector installer code signing. The current prototype package is unsigned.
Self-serve account export and data deletion controls. Requests are handled by email until these ship.
Bank-settlement confirmation for deposit reconciliation.
SOC 2 Type II. We are not SOC 2 certified today, and we will publish the report date when we hold it, not one day before.
Independent third-party penetration test, summary published.
Signed Data Processing Addendum, and email notice of subprocessor changes.
Single sign-on (SAML / SSO) for larger chains.
Customer-managed encryption keys.
A published coordinated-disclosure policy.

A roadmap item is a roadmap item until it is real and checkable, at which point it moves to the left column with a date. If a page ever claims otherwise, it is wrong, and this line is the one to trust.

Found something? Tell us.

If you or your technician find a security problem, report it to [email protected]. If that address ever fails, [email protected] reaches the founder. We read these, we respond, and we do not pursue good-faith research that follows responsible disclosure.