Trust is foundational to how Kueso is built. Learn how we approach data protection, responsible AI, and the ongoing development of our security program.
Kueso brings restaurant operations, team knowledge and AI assistance into one place. That creates a responsibility to handle business information thoughtfully, explain clearly how the service works, and make security part of the product rather than an afterthought.
Kueso is built on established infrastructure rather than a proprietary database or identity system created from scratch. Security follows a shared-responsibility model: our providers operate the underlying infrastructure under their own security programs, and Kueso is responsible for the application logic that decides what each person can do with the information stored there.
This page separates four kinds of statements, so it is always clear what each one rests on.
The controls below are application-level safeguards supported by our internal application security review. They describe how Kueso is designed to behave in ordinary product workflows. We do not claim that every production database policy, storage path or alternate access route has been independently tested; validating these controls is part of our ongoing program.
Authenticated requests to Kueso’s services use verified sign-in tokens. The service determines who is making a request from that verified token, rather than trusting a user identifier supplied by a device. Requests without valid authentication are rejected on authenticated routes.
Sign-in and identity services run on Supabase’s managed authentication infrastructure.
Kueso organizes restaurant work into Spaces and channels. Application-level authorization checks are designed to limit channel messages and content to the owner and participating members. Access is determined by membership, not by knowing a channel’s identifier.
Different operational tools use permission models suited to their purpose, and documents in the application follow the applicable workspace and tool permissions.
Kueso’s assistant is intended to work within the permissions of the signed-in person, not as an unrestricted administrator of a restaurant’s information. For supported workflows, it retrieves information through permission-aware tools that use the signed-in user’s identity, so answers are grounded in information that person can access through the application.
Sensitive actions, such as sending messages or emails and making certain operational changes, use confirmation flows. Kueso presents a draft for review before the action is carried out. Routine read-only assistance does not require the same confirmation.
Employee Intelligence is designed around independently owned staff directories. It keeps staff profiles separate from app accounts, uses owner-managed access with explicit manager invitations, and reserves compensation information for the directory owner. When a roster is imported, managers review the extracted information before it is saved.
These are product controls of the Employee Intelligence module and apply where that module is enabled. Availability of individual tools may vary by deployment.
Integrations such as Slack and Gmail are optional. They are connected by users to enable specific workflows, and they are relevant only when a customer chooses to connect them. Supported outbound messages sent through a connected account require confirmation before they are sent.
Temperature Logs is designed to preserve submitted readings and to keep versions of published log templates, which helps retain the history and context of each operational check. Participation is managed by the log’s creator, with controlled permissions for who can submit readings.
Kueso also helps teams organize restaurant documents, procedures and operational knowledge so authorized users can find answers without searching disconnected systems. Document access follows workspace and tool permissions. The privacy of shared file links is a separate area of ongoing verification and improvement.
These records support, but do not replace, a restaurant’s own food-safety procedures, training and regulatory responsibilities.
Kueso uses Stripe and Apple for supported payment flows. Kueso does not collect payment card numbers directly in its application.
Kueso uses Anthropic and OpenAI for AI capabilities. To process a request, relevant prompts, conversation context and retrieved material may be sent to the provider needed for that request. This is an important part of how the service works, and we believe customers should understand it.
Anthropic maintains a public Trust Center with compliance documentation and controls for its API services. OpenAI states that data sent to its API is not used to train its models by default unless a customer explicitly opts in; separate abuse-monitoring and feature-specific retention terms may apply.
These statements describe the providers’ published policies. They are not an independently verified description of a Kueso-specific retention configuration.
Kueso combines its own application controls with specialized services from established providers. The list below explains what each provider contributes. Where a provider publishes independent certifications or security controls, those are attributed to the provider. Using a certified provider does not make Kueso certified, and Kueso does not inherit any provider’s certification.
Managed database, authentication and storage
Supabase states that its hosted platform is SOC 2 Type II compliant and ISO 27001 certified, with platform controls assessed annually. It also documents AES-256 encryption for database data and backups and TLS protection for data in transit within its managed infrastructure. These are Supabase’s attestations and safeguards. The permissions an application configures, and the security of its own code, remain the application’s responsibility.
SOC 2 compliance (opens in a new tab) Security overview (opens in a new tab)
Application hosting
Render hosts Kueso’s application services. Render publishes information about its own security practices and compliance program.
AI processing
Anthropic maintains a public Trust Center with its own security and compliance documentation for its API services.
AI processing and indexing-related capabilities
OpenAI documents how data sent to its API is handled, including that API data is not used to train its models by default unless a customer opts in.
Payment processing
Stripe processes supported payments, so card details are handled by Stripe rather than collected directly in Kueso’s application. Stripe publishes its own security and compliance documentation.
Payment processing for supported in-app purchases
Supported purchases made in Kueso’s iOS app are processed by Apple. Apple publishes documentation on the security of its platforms and services.
Slack and Google provide optional connected account services. They are involved only when a customer chooses to connect them. Specific provider usage and contractual arrangements are reviewed as the product evolves.
Product safeguards and customer practices work together. Restaurant operators remain in control of their operations, and we recommend that teams:
Kueso is developing its security practices with SOC 2 readiness as a long-term objective. SOC 2 describes a direction for how our program develops, not a credential we hold: Kueso is not SOC 2 certified and does not claim SOC 2 or ISO 27001 certification.
The work is organized into six workstreams. Each shows what is in place, what is in progress and what is planned.
Security is not a one-time release. The roadmap below describes continuous improvement on top of the protections already in place, as customer needs and the product grow.
Continued improvements to data safeguards, access controls and file security.
Security testing, monitoring, reviews and documented verification.
Formal security operations, customer data controls and preparation for independent assessments.
When a new control is implemented and verified, we will describe it here as part of Kueso’s current security posture. Until then, it remains a planned initiative.
For security questions or responsible disclosure inquiries, contact espinobrian50@gmail.com. Security inquiries are reviewed and prioritized based on urgency.
This page describes Kueso’s reviewed application safeguards and the published assurances of the providers we use, as of the date above. It is informational and is not a contractual security guarantee. Kueso does not claim SOC 2 or ISO 27001 certification or an independent penetration test. Provider certifications belong to the providers named.
Public resources behind the third-party statements on this page. Statements about Kueso’s application are based on our internal application security review.