{% set page_title = "Security Overview" %}
{% set page_desc = "Developum AI Inc. — how we secure customer data across the EVOLUM platform. Deterministic engine, no cloud AI dependency, Supabase RLS, encrypted infrastructure." %}
{% set eyebrow = "Security" %}
{% set title_html = "Security <em>Overview.</em>" %}
{% set effective_date = "July 1, 2026" %}
{% set active = "security" %}
{% extends "_legal_shell.html" %}

{% block body %}

<p>This page describes the technical controls that protect the data our customers trust us with. It is written to be legible to engineers, auditors, and enterprise buyers doing security diligence.</p>

<h2>The <em>Non-Negotiables</em></h2>

<ul>
  <li><strong>Screenplays never leave the platform for AI processing.</strong> The EVOLUM engine is a local, deterministic Python + JSON pipeline. No customer creative content is transmitted to third-party LLM providers (OpenAI, Anthropic, Google, etc.).</li>
  <li><strong>All data is encrypted in transit.</strong> TLS 1.2+ enforced end-to-end via Caddy reverse proxy with automatic certificate rotation.</li>
  <li><strong>All data is encrypted at rest.</strong> AES-256 via Supabase-managed Postgres storage. Physical disks are Hetzner-managed with hardware-level encryption.</li>
  <li><strong>Payment card data never touches our servers.</strong> All payment collection and processing is handled by Stripe under their PCI-DSS Level 1 attestation. We store only Stripe customer IDs and subscription references.</li>
</ul>

<h2>Data <em>Architecture</em></h2>

<div class="lgrid">
  <div class="lgrid-cell">
    <div class="k">Application Data</div>
    <div class="v"><strong>Supabase (Postgres)</strong>. Row-Level Security enforced on every table containing customer content. RLS policies audited weekly via automated script. Backups: daily automated SQL dumps with verification.</div>
  </div>
  <div class="lgrid-cell">
    <div class="k">Authentication</div>
    <div class="v"><strong>Supabase Auth</strong>. JWT-based session tokens with 1-hour expiry and rotation. Passwords hashed with bcrypt. Optional MFA available.</div>
  </div>
  <div class="lgrid-cell">
    <div class="k">File Storage</div>
    <div class="v"><strong>Supabase Storage</strong>. Private buckets with signed URLs (1-hour default expiry, auto-refreshed). No public direct-access URLs for customer content.</div>
  </div>
  <div class="lgrid-cell">
    <div class="k">Infrastructure</div>
    <div class="v"><strong>Hetzner Cloud</strong>. EU/US data centers, physical security handled by Hetzner. Server-level firewalls, SSH-key-only access, no password authentication.</div>
  </div>
  <div class="lgrid-cell">
    <div class="k">Payments</div>
    <div class="v"><strong>Stripe</strong>. All payment methods, subscription state, and card details stored by Stripe. We store only opaque customer + subscription IDs and event webhooks.</div>
  </div>
  <div class="lgrid-cell">
    <div class="k">Email Notifications</div>
    <div class="v">Transactional email sent via SMTP through <strong>Supabase Auth</strong>. Content is limited to authentication flows (verify email, reset password) — no marketing.</div>
  </div>
</div>

<h2>Access <em>Controls</em></h2>

<ul>
  <li><strong>Principle of least privilege.</strong> Every user role has the minimum permissions needed for their function.</li>
  <li><strong>Row-Level Security</strong> enforced at the database layer — even if application code has a bug, users cannot read or write another user's rows.</li>
  <li><strong>Admin access</strong> requires SSH keys with passphrase. No password login is enabled on production servers.</li>
  <li><strong>Session tokens</strong> rotate every hour. Compromised tokens have a bounded blast radius.</li>
  <li><strong>Access reviews</strong> conducted per the Access Control Policy documented in our SOC-2 package.</li>
</ul>

<h2>Monitoring & <em>Incident Response</em></h2>

<ul>
  <li>Application-level errors captured and dispatched via our incident alerter.</li>
  <li>Systemd service health monitored on all production processes with automatic restart on failure.</li>
  <li>Weekly RLS audit script confirms row-level security policies remain intact after schema changes.</li>
  <li>Daily backup verification script confirms recoverable database dumps exist.</li>
  <li>Incident response follows a documented playbook (containment → eradication → notification → post-mortem). Customer notification within 72 hours of confirmed data-affecting incident.</li>
</ul>

<h2>What We <em>Don't</em> Do</h2>

<ul>
  <li>We <strong>do not</strong> train third-party AI models on customer data.</li>
  <li>We <strong>do not</strong> transmit screenplays, treatments, or creative content to external AI APIs.</li>
  <li>We <strong>do not</strong> sell customer data to advertisers or data brokers.</li>
  <li>We <strong>do not</strong> retain deleted customer content beyond backup rotation windows (documented in the DR/BCP).</li>
  <li>We <strong>do not</strong> permit direct database access to anyone outside the engineering team.</li>
</ul>

<h2>Reporting a <em>Vulnerability</em></h2>

<p>Security researchers and users who identify a vulnerability are asked to disclose responsibly by emailing <a href="mailto:security@developumaiengine.com">security@developumaiengine.com</a>. Please do not publicly disclose until we have had reasonable time to remediate (typically 30-90 days depending on severity). We do not currently operate a paid bounty program, but we credit disclosures publicly if the researcher requests it.</p>

<h2>More <em>Detail</em></h2>

<p>For the full security posture — access control policy, change management policy, incident response plan, DR/BCP with RTO/RPO metrics, and system evidence — see our <a href="/trust">Trust Center</a> or write to <a href="mailto:security@developumaiengine.com">security@developumaiengine.com</a> for the auditor package.</p>

{% endblock %}