Security & Operations Policies

Ragbee is operated by a small engineering team. These policies describe the controls actually in place in production today. They are reviewed with each security-relevant release and updated as the platform evolves. Security reports: support@ragbee.ai.

1. Security Policy

• Access control: server access is SSH key-only; no password authentication. Services run under least-privilege user accounts managed by systemd.
• Secrets management: credentials exist only in server-side environment files (restricted permissions), excluded from version control. No secrets in code, logs, or client-side storage.
• Network: host firewall (UFW) allows only SSH, HTTP, and HTTPS; default-deny for all other inbound traffic. All traffic is TLS-encrypted (HSTS enforced).
• Tenant isolation: all documents, embeddings, and chat data are scoped to per-tenant workspaces; no cross-tenant query path exists.
• Inbound integrity: every platform webhook is signature-verified (HMAC-SHA256 with replay window for Zoom; equivalent signing secrets for Slack/Messenger); unverified requests are rejected.
• Rate limiting: enforced at the reverse proxy and application layers per client and per integration.
• PII handling: personal information is redacted from logs and prompts before storage or model calls; unverified public channels cannot process credential-shaped input.

2. Vulnerability Management Policy

• Static analysis (SAST): all Python services are scanned with Bandit on an automated weekly schedule and before security-relevant releases. Reports are retained as dated JSON artifacts.
• Dynamic testing (DAST): the OWASP ZAP baseline scan runs against production at each security-relevant release and on demand. Most recent scan: 0 failing checks, 55 passing checks.
• Triage targets: High severity — investigate within 1 business day, remediate or mitigate within 7 days. Medium — within 5 business days / 30 days. Low and informational — reviewed in the regular cycle.
• Findings register: scan reports and triage notes are retained under version-controlled archives with dates; remediation happens through the normal change process (git-tracked, reviewed commits).

3. Data Retention & Protection Policy

• Tenant data is retained while the subscription is active. On cancellation or documented deletion request, tenant data (documents, embeddings, chat history) is deleted or de-identified within 30 days, except where retention is legally required.
• Uploaded documents are stored in private, access-controlled object storage; embeddings and metadata in the tenant-scoped database.
• Personal information in message logs is redacted at capture time; retention follows the privacy policy.
• Development and testing use mock data providers — no production customer data is used for development or testing.
• No customer data is used to train machine-learning models. LLM processing uses the tenant's own retrieved content only, via providers under API agreements that exclude training use.

4. Incident Management & Response Policy

• Reporting: suspected security incidents are reported to support@ragbee.ai and acknowledged within 1 business day.
• Response process: (1) confirm and classify severity; (2) contain — affected functionality can be isolated via per-service systemd units, firewall rules, or immediate rollback to the previous git revision; (3) eradicate and recover; (4) notify affected customers and, where the Zoom integration is implicated, Zoom marketplace review, without undue delay (target: within 72 hours of confirmation); (5) post-mortem with corrective actions recorded as tracked engineering items.
• Rollback: every production deploy is a reversible, version-controlled change; the previous revision can be restored within minutes.

5. Infrastructure & Dependency Management Policy

• All third-party dependencies are pinned to exact versions in per-service requirements files; upgrades are deliberate, reviewed changes, not automatic.
• Operating system and runtime security updates are applied on a regular maintenance schedule with service health checks after restart.
• TLS certificates are managed with automated renewal (Let's Encrypt); expiry is monitored as part of routine checks.
• Infrastructure changes (nginx, firewall, systemd) follow the same change-control process as application code: reviewed, applied deliberately, verified with health checks, reversible.
• Service availability is monitored; each deploy is followed by automated endpoint smoke tests.

6. Certifications

Ragbee has not undergone SOC 2 or ISO 27001 certification at this time. The controls described above are aligned with the underlying principles of those frameworks (access control, change management, vulnerability management, incident response). Formal certification will be considered as the customer base grows.