Tenant data isolation
Each restaurant receives a separate tenant database. Authenticated application services resolve the current restaurant before opening tenant data, and public agent catalog endpoints never open a restaurant database.
Security at Rosuii
Restaurant data is separated by design
Rosuii is a multi-tenant restaurant platform, but restaurant operational data is not stored as one shared set of tenant rows. Each restaurant tenant is provisioned with its own MySQL database and application requests are resolved into that tenant context.
Repository and document review:
Authentication and permissions
Panel access uses authenticated sessions. Restaurant roles and granular permissions control operational actions, and account status can be disabled when access should stop.
API-key handling
Restaurant integration keys use an rsk_ secret shown to the owner when created. Rosuii stores a SHA-256 hash for lookup rather than storing the presented raw key in the central key table.
Tenant-scoped APIs
A verified restaurant API key determines the tenant. The caller does not provide a tenant ID that can be changed to request another restaurant's customers, staff, orders or reports.
Public AI endpoints
The public Agent API and read-only MCP server expose product facts, features, pricing and FAQ. They do not provide public tools for restaurant orders, customers, staff, inventory or sales.
Abuse controls
Public Agent API, event collection and MCP routes apply endpoint-specific rate limits. MCP requests also validate the browser Origin when one is supplied.
What restaurant owners should control
- Use a unique password and restrict shared logins.
- Give each role only the permissions it needs.
- Create API keys only for trusted integrations and revoke keys that are no longer needed.
- Keep payment-gateway credentials private and use sandbox mode before going live.
- Report unexpected access or activity promptly.
Buyer questions about security and data
This is a review of code and published documentation, not a live recovery drill or independent penetration test.
How are restaurants separated?
The implementation provisions a separate MySQL database for each restaurant tenant. Authenticated requests and integration keys resolve a tenant before accessing its operational data. This design does not replace testing of authorization controls.
How are passwords and API keys handled?
Passwords are hashed. Restaurant integration keys are shown when created; the central key lookup stores a SHA-256 hash, with revocation support. Keep keys out of shared documents and revoke keys that are no longer needed.
What encryption is documented?
The privacy policy describes HTTPS/TLS protection in transit. Password and API-key hashing have distinct purposes. A blanket promise of encryption at rest for all records, credentials and backups is not established by this review.
What is the backup retention and restore policy?
The repository review did not establish an approved automatic-backup schedule, retention period, recovery-time target, recovery-point target or recent restore-test result. Ask Rosuii for written terms and a restore demonstration before relying on a recovery commitment.
When is restaurant data deleted?
The privacy policy describes retention while an account is active and where records are needed for legal, tax, accounting or dispute purposes. Account closure may lead to deletion or anonymisation subject to those exceptions. It does not establish a fixed deletion deadline or backup-purge period.
Can I export my data?
Report export is a plan-dependent feature, not a promise of a complete portable database backup. Specify the records, period and file formats you need; test available exports and confirm any account-exit assistance before purchase.
What happens if there is an incident?
Report suspected security issues to support@rosuii.com without passwords, payment credentials or unnecessary personal data. This review found no approved public incident-history register, guaranteed response time or 24/7 support schedule. Missing public records must not be read as zero incidents.
Has Rosuii passed an independent security review?
No publishable independent review, penetration-test report or certification was established in the repository sources reviewed for this page. The architecture description is not an assurance report. Any future assurance should state its assessor, scope, date and unresolved limitations.
Report a security concern
Email support@rosuii.com with a concise description, affected URL or account context and safe reproduction steps. Do not include passwords, live payment credentials or unnecessary customer data. Please give the team reasonable time to investigate before public disclosure.