Security & Access Policy

Effective date: May 2026

This document describes the security measures Muxbe has in place to protect your data, how access controls work, and what you can realistically expect from us. We believe trust comes from honesty, so this page tells you what we actually do — not what sounds impressive on a slide deck.

Muxbe is operated by Giorgi Kurtsikidze, Individual Entrepreneur (მცირე მეწარმე), registered in Georgia, under the trade name Muxbe. We are a B2B SaaS platform for iGaming affiliate management.

1. Infrastructure

Muxbe runs on established, enterprise-grade cloud infrastructure provided by a small number of carefully selected third-party providers:

• Backend: A managed cloud platform provides our realtime database, document database, file storage, serverless compute, scheduled task queue, and managed secrets vault.
• Frontend: Served via a global content delivery network for fast, low-latency delivery worldwide.
• Background jobs: A managed task queue handles scheduled and asynchronous processing.
• Encryption in transit: All communications between your browser and our servers are encrypted using HTTPS/TLS. There are no unencrypted endpoints.
• Encryption at rest: All stored data is encrypted at rest by our cloud infrastructure provider's default infrastructure encryption.

We rely on our cloud infrastructure providers' physical security, network security, and infrastructure hardening. We do not operate our own data centers or servers. The current named list of our infrastructure providers is included in the Sub-processor list delivered to Customers under contract.

2. Authentication

All user authentication is handled through the platform's authentication system:

• Email and password login only — no social login or OAuth providers.
• Every backend endpoint verifies the authentication token server-side before processing any request.
• Password reset is handled through a built-in, audited password reset flow.
• Auth tokens are short-lived and validated on every API call.

3. Authorization & Access Control

Muxbe enforces role-based access control (RBAC) with a deny-by-default permission model. If a permission is not explicitly granted, it is denied.

3.1 Roles

The platform supports the following roles: superadmin, admin, ceo, project_manager, manager, retention, viewer, and custom role templates that can be configured per tenant.

3.2 Granular Permissions

Each role is assigned a specific set of permissions that control what the user can see and do:

Permissions are enforced both in the browser (UI elements are hidden or disabled) and on the server (Cloud Functions reject unauthorized requests). The server-side check is the authoritative one — client-side checks exist for user experience, not security.

4. Tenant Isolation

Muxbe is a multi-tenant platform. Each customer's data is isolated under a dedicated path: tenants/{tenantId}/.

• Every user is bound to a specific tenant through their profile. A user cannot access another tenant's data.
• Cloud Functions resolve the tenant context from the authenticated user's profile — there is no client-side tenant switching.
• Database security rules enforce that reads and writes stay within the user's tenant boundary.

We want to be straightforward: this isolation works and is enforced at the database rules level, but it has not been independently audited by a third party. We test it, we enforce it in code and rules, and we believe it is sound — but we are not going to call it "enterprise-grade certified isolation" because that would require a formal audit we have not completed.

5. PII Protection

Muxbe handles two categories of personally identifiable information, and both receive additional protection beyond standard access controls:

5.1 Player PII

Player personal data — including email, name, nickname, and IP address — is stored in a separate playersPII collection. Access requires the explicit viewPlayerPII permission. Users without this permission cannot see player personal details, even if they can see aggregated player statistics.

5.2 Partner Contacts

Partner contact information — including email, phone, Telegram, and Skype — is stored in a separate partnerContacts collection. Access requires the explicit viewPartnerContacts permission.

5.3 AI Assistant & PII

The AI assistant is permission-aware. When a user queries the assistant, PII and financial fields are stripped from AI tool results if the user lacks the appropriate permission. A user without viewPlayerPII cannot extract player personal data through the AI assistant.

6. Secret Management

• API keys and credentials (for AI providers, email providers, third-party data sources, and HMAC signing) are stored in a managed secrets vault, not in source code or environment variables.
• Per-tenant integration credentials (e.g., each customer's API key for their affiliate management platform) are stored with controlled access and are not exposed to other tenants.
• API key rotation is supported — keys can be updated in Secret Manager without redeploying the application.

7. Background Worker Security

Muxbe uses a managed task queue for scheduled background processing (e.g., daily statistics collection). These workers are protected by multiple authentication layers:

• OIDC token verification: Each task includes a Google-signed OIDC token tied to a specific service account.
• Service account validation: The receiving function verifies the calling service account identity.
• HMAC signature: Each task payload is signed with an HMAC secret from Secret Manager and verified on receipt.
• Tenant whitelist: Only explicitly whitelisted tenants can have background tasks executed.

This multi-layer approach means that even if one verification step were bypassed, the others would still block unauthorized execution.

8. Audit Logging

• Muxbe maintains an audit log of user actions, including: the action performed, the user's email, name, and UID, client IP address, user agent, and the subject and details of the action.
• Audit log export (CSV) is restricted to superadmin users.
• Backend logs are captured by our cloud infrastructure provider's managed logging service.

9. Data Retention & Deletion

We retain data for as long as needed to provide the service, and we have automated cleanup for certain data types:

9.1 Deletion Capabilities

• Tenant deletion: Complete removal of all tenant data, registry entry, associated user profiles, and authentication accounts.
• User deletion: Removes user profile, presence data, and the user's authentication account.
• Invoice deletion: Removes both the database record and the associated file from Cloud Storage.

10. Platform Operator Access

10.1 When Operator Access Is Used

Superadmin access is used only for legitimate platform operations:

• Responding to customer support requests;
• Investigating and resolving security incidents;
• System maintenance, debugging, and infrastructure management;
• Fulfilling customer requests (e.g., data export, account changes);
• Complying with legal obligations.

10.2 What Operator Access Is NOT Used For

The platform operator does not access customer data for:

• Commercial exploitation or monetization of customer data;
• Competitive intelligence or benchmarking;
• Curiosity or any reason unrelated to platform operation;
• Sharing with third parties outside of what is described in our Privacy Policy and Subprocessors list.

10.3 Safeguards

• All customer data access is subject to the confidentiality obligations described in our Terms of Service.
• Sensitive administrative actions are logged where technically feasible through our audit log system.
• Customer data access is tied to support requests or operational needs whenever possible.
• We do not have employees or contractors with access — it is limited to the operator.

10.4 The Honest Reality

In large companies, operator access is governed by formal internal policies, access review boards, and separation-of-duties controls. Muxbe is a solo-operated platform, so we cannot offer that same organizational structure. What we can offer is:

• Direct accountability — there is one person responsible, and you know exactly who it is;
• Contractual confidentiality — our Terms of Service and DPA create binding obligations;
• Technical logging — admin actions are recorded;
• A commitment to transparency — this section exists because we think you should know.

11. What We Do NOT Claim

We think it is just as important to tell you what we have not done as what we have:

• We are not SOC 2 certified and we are not ISO 27001 certified.
• Our tenant isolation has not been independently audited by a third-party security firm.
• We do not have a formal bug bounty program (though we welcome responsible disclosure at security@muxbe.com).
• We do not claim "zero access" to customer data — see Section 10 above.
• We do not guarantee that our platform is immune to security incidents. No one can.

We are continuously improving our security posture. If certifications or audits become relevant to our customers, we will pursue them and update this page accordingly.

12. Incident Response

If we become aware of a security breach that affects your data, we will:

1. Notify you within 72 hours where feasible, as required by GDPR Article 33;
2. Describe the nature of the breach and the categories of data affected;
3. Explain the measures we have taken or plan to take to address the breach and mitigate its effects;
4. Provide a point of contact for follow-up questions.

We will keep you updated as we learn more. We will not wait until we have all the answers to begin communicating — timely, honest updates matter more than a polished post-mortem.

13. Responsible Disclosure

If you discover a security vulnerability in Muxbe, we ask that you report it responsibly:

• Email: security@muxbe.com
• Include a description of the vulnerability, steps to reproduce, and any relevant evidence.
• Give us reasonable time to investigate and address the issue before any public disclosure.

We appreciate security researchers who help us improve. We will acknowledge your report and work to resolve confirmed vulnerabilities promptly.

14. Your Responsibilities

Security is a shared responsibility. As a Muxbe customer, you play an important role:

• Use strong, unique passwords for your Muxbe accounts.
• Do not share login credentials between users — create individual accounts instead.
• Review and configure role permissions appropriately for your team members.
• Keep your third-party API credentials (for your affiliate platform, marketing automation platform, and any other integrated services) secure.
• Report any suspected unauthorized access immediately to security@muxbe.com.
• Ensure you have a lawful basis for any personal data you upload to Muxbe.

15. Changes to This Policy

We may update this Security & Access Policy from time to time as we improve our security practices or as our infrastructure evolves. Material changes will be communicated via email to account holders. The effective date at the top of this page reflects the latest revision.

16. Contact

For security concerns, vulnerability reports, or questions about this policy:

• Security contact: security@muxbe.com
• General legal: legal@muxbe.com
• Operator: Giorgi Kurtsikidze, Individual Entrepreneur
• Location: Georgia