Built for store data founders do not hand out lightly.
Ops Room connects to systems that make money: commerce, inventory, support, ads, analytics, payments, email, files, and operating conversations. The trust model is simple: tenant-scoped reads, explicit approval before writes, and an audit trail for what happened.
- Access-gated app and membership-gated workspaces
- External writes pause for founder approval
- Active uploaded content blocked or forced to download
- Webhook ingress signed and verified
The controls we can defend today.
Access and membership
Cloudflare Access verifies identity, then Ops Room resolves that email to a workspace membership before routing any app, API, or chat request.
Tenant-scoped state
Each workspace routes to isolated Durable Object state. Uploaded artifacts use tenant-prefixed R2 keys and authenticated read endpoints.
Approval-gated writes
External mutations are AI SDK approval tools. The call pauses in chat and executes only after the founder approves the exact action.
Append-only audit trail
Reads, approval requests, grants, denials, connector calls, and outcomes land in the Operating Ledger. SQLite triggers prevent mutation of ledger rows.
Encrypted connector credentials
Tenant connector secrets are encrypted at rest with WebCrypto AES-GCM and random IVs. A separate credential broker is planned but not yet the production boundary.
Read freely. Draft freely. Write only after approval.
Scheduled runs strip approval-required tools so the agent cannot queue an unattended write that waits forever or fires outside the founder’s review path.
Orders, stock, tickets, campaigns, analytics, files, marketplace evidence, and recent operating history.
Replies, purchase orders, disputes, inventory changes, vendor follow-ups, runbooks, and brief recommendations.
External writes, config changes, canonical memory, and any action with business side effects.
Only after an inline approval card is granted by the founder in the app thread.
What connected systems are used for.
| System | Reads | Write posture |
|---|---|---|
| Shopify | Orders, products, customers, inventory | Draft orders and Admin mutations behind approval |
| Zoho Inventory | Items, stock, contacts, purchase and sales docs | Purchase orders, contacts, and sales docs behind approval |
| Zoho Desk | Tickets, contacts, departments, threads | Ticket updates and replies behind approval |
| Amazon SP-API | Orders, inventory, listings, marketplace context | Seller actions behind approval |
| Google Ads / Meta Ads | Accounts, campaigns, ad sets, metrics | Campaign changes behind approval |
| Google Analytics | Properties, reports, source and audience metrics | Read-only in v1 |
| Gmail | Messages, threads, labels, search | Drafts and label changes behind approval |
| Razorpay | Payments, orders, refunds, settlements, disputes | Capture, refund, and payment-link actions behind approval |
What is still in progress.
- The credential broker is designed but not yet the runtime boundary; current production decrypts tenant credentials inside the Worker runtime.
- Production trace promotion and eval replay need an explicit tenant policy before we can claim full admin/eval data isolation.
- Ledger retention, export, and deletion policy needs to be formalized before customer security questionnaires ask for a deletion SLA.
- SOC 2 is not complete. Today we provide architecture-level controls, audit logs, and a public remediation roadmap.
Bring the security questions early.
We can walk through data flow, connector scopes, approval evidence, and the current remediation roadmap before you connect production systems.