THIS SECURITY POLICY (the "Security Policy") describes the technical and organizational measures implemented by:

NADIRAOS LLC, a Wyoming limited liability company (the "Company"), to protect data stored and processed within its software-as-a-service platform (the "Service").

This Security Policy is incorporated into and forms part of the Company's Terms and Conditions (the "Terms"), available at [Terms URL].

1.1 Multi-Tenant Database Isolation

Each organization ("Workspace") on the Service is provisioned with a dedicated, logically isolated database. Unlike shared-schema multi-tenant architectures where all tenants share the same tables, the Service uses a separate database per Workspace. This means:

• Your data is stored in its own database, not intermingled with other organizations' data.
• A query or application error in one Workspace cannot read, modify, or affect another Workspace's data.
• Database access credentials are scoped to the individual tenant database.

1.2 Per-Tenant Filesystem Isolation

File uploads and generated assets are stored in per-Workspace filesystem roots (tenant_{id}/). One Workspace cannot access another Workspace's files through the application layer.

1.3 Cache & Queue Isolation

Redis cache keys and queue jobs are namespaced per Workspace, preventing cache collisions or cross-tenant job interference.

2.1 Encryption in Transit

All communication between clients and the Service is encrypted using TLS 1.2+. HTTP connections are automatically redirected to HTTPS.

2.2 Encryption at Rest

• Database: The underlying database infrastructure encrypts data at rest.
• Credentials & Secrets: Integration credentials (e.g., API keys for third-party services) are encrypted at rest in the tenant database using AES-256-CBC.
• File Storage: Uploaded files stored on cloud disks inherit the provider's encryption-at-rest capabilities.

3.1 Authentication

• User authentication is managed via secure session-based authentication with encrypted session cookies.
• Two-factor authentication (2FA) is available and enforced for account owners.

3.2 Authorization

• Access to individual applications within a Workspace is governed by an App Gate — a middleware-level enforcement layer that checks whether a user's role permits access to the requested app.
• File uploads and downloads are routed through a dedicated upload/download gate that validates file paths, MIME types, and permissions. Raw filesystem access is prohibited by static code enforcement tests.

3.3 Integration Egress

All outbound requests to third-party integrations are routed through a single egress gateway with per-integration credential vaulting. Individual controllers cannot make arbitrary external requests.

4.1 Input Validation & Output Escaping

All user input is validated server-side. Blade templating automatically escapes output to prevent XSS. SQL injection is prevented through exclusive use of Eloquent ORM parameterized queries.

4.2 Security Headers

The Service sets the following HTTP security headers on all responses:

• Content-Security-Policy — restricts resource origins
• Strict-Transport-Security — enforces HTTPS with preload
• X-Content-Type-Options: nosniff
• X-Frame-Options: DENY (or CSP frame-ancestors)
• Referrer-Policy — limits referrer information leakage

4.3 Rate Limiting

Authentication, API, and public form endpoints are protected by rate limiting to mitigate brute-force and abuse attacks.

4.4 Session Security

• Session cookies are encrypted and marked HttpOnly and SameSite=Lax.
• In production, cookies use the Host prefix and Secure flag.

5.1 Server Hardening

Production servers run a minimal service surface with SSH key-only authentication, firewall restricting inbound traffic, and automatic security updates.

5.2 Database Backups

Database backups are performed regularly with point-in-time recovery capability. Backups are encrypted and stored separately from the production infrastructure.

5.3 Deployment Pipeline

Code changes are gated by automated test suites (SQLite + MySQL) before deployment. Production deployments are performed via an atomic symlink swap with automatic health checks and rollback capability.

6.1 Reporting a Vulnerability

If you believe you have discovered a security vulnerability in the Service, please report it immediately to security@nadiraos.com with:

• A description of the vulnerability and its potential impact
• Steps to reproduce the issue
• Any proof-of-concept code or screenshots

We commit to acknowledging receipt within 48 hours and providing an initial assessment within 5 business days.

6.2 Notification

In the event of a confirmed data breach affecting your Workspace, the Company will notify affected account owners within 72 hours of confirmation, including the nature of the breach, steps taken to contain it, and recommended actions.

7.1 Workspace Data

Data within your Workspace is retained for as long as your Workspace is active. Upon cancellation, Workspace data is retained for 30 days to allow for reactivation, after which it is permanently deleted from the database and all backups.

7.2 Audit Logs

Security-relevant events (file uploads, downloads, deletions, integration access) are logged within the tenant database for the Workspace owner's review.

This Security Policy is designed to align with the security expectations of:

• GDPR (General Data Protection Regulation) — Article 32 (Security of processing)
• CCPA (California Consumer Privacy Act) — reasonable security measures
• SOC 2 Trust Services Criteria — Security and Availability

Formal compliance certifications may be pursued as the Service matures. For the current status, contact security@nadiraos.com.

Questions about this Security Policy or the Service's security practices can be directed to security@nadiraos.com.