ModelMeld
Trust & Security

Security at ModelMeld

Effective date: May 26, 2026 · Last updated: May 26, 2026

This page describes our security posture: how we protect customer data, how the gateway is architected, our vulnerability-disclosure program, and our compliance roadmap. Where claims can be verified against running code, we cite the file in the public OSS repo.

This page is informational. It does not modify the Terms of Service or any executed agreement. Corrections and reports: security@modelmeld.ai.

1. Reporting a vulnerability

  • Email: security@modelmeld.ai
  • Acknowledgement target: we aim to acknowledge reports within 2 business days. This is an internal target, not a contractual commitment.
  • Triage target: we aim to provide an initial severity assessment and remediation plan within 5 business days. Same caveat.
  • Severity scoring: CVSS 3.1. We publish our CVSS vector with each advisory.
  • CVE handling: we request CVE IDs via GitHub Security Advisories for confirmed vulnerabilities in the modelmeld package.

Scope: modelmeld.ai (this site), api.modelmeld.ai (the hosted gateway), the modelmeld PyPI package, and any code in the public github.com/modelmeld/modelmeld repository.

Out of scope: third-party systems we depend on (Render, Vercel, Stripe, Anthropic, OpenAI, etc.). Report those to the upstream vendor directly.

Reporting expectations:

  • Do not publicly disclose the vulnerability until we've had a reasonable opportunity to remediate.
  • Do not access, modify, or destroy data that doesn't belong to you.
  • Do not run automated scans that degrade service for other users.
  • Do not attempt social engineering against ModelMeld personnel or any third-party vendor's staff.

Safe harbor: If you make a good-faith effort to comply with this policy during your security research, we will consider your research authorized under the Computer Fraud and Abuse Act, the DMCA anti-circumvention provisions, and applicable state computer-crime laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy. This authorization does not extend to: (i) actions that intentionally compromise the privacy or safety of our users or third parties; (ii) access to data beyond the minimum necessary to demonstrate the vulnerability; (iii) testing against third-party systems (e.g., our hosting providers or sub-processors) — you must contact those parties directly; or (iv) any conduct that violates laws other than those specifically authorized above. We cannot and do not authorize action against third parties on their behalf.

We don't currently run a paid bug bounty. We will publicly acknowledge contributors who disclose responsibly, if you'd like to be credited.

2. Threat model

Primary trust boundary is the gateway HTTP surface. We assume TLS is intact, the host OS is patched by Render, and customer API keys are kept secret by the customer.

In scope for our security posture:

  • The gateway and its routing logic
  • Authentication (license JWT, API key, BYOK header)
  • The audit log and billing pipeline
  • The OSS package supply chain (pip install modelmeld)

Out of scope for our security posture:

  • Upstream provider compromise (Anthropic, OpenAI, Fireworks, Together, OpenRouter)
  • Customer-side prompt injection
  • Social engineering of customer staff
  • Misuse of the hosted service by an authorized customer

3. Authentication

Two distinct credential types, each scoped to a specific surface:

License JWT — issued at checkout. EdDSA over Ed25519 (RFC 8037): deterministic, side-channel-resistant, constant-time verification via the cryptography library's libsodium-backed primitive. We do not accept HS256/RS256 — the alg field is pinned in the verifier (src/modelmeld/licensing.py) so alg: none downgrades and HMAC-with-public-key confusion attacks don't apply by construction. The header kid is a 128-bit truncated SHA-256 of the raw public key; rotation is supported by issuing tokens under a new kid, and the verifier rejects mismatches before any signature work so revoked keys can never validate even within their exp window.

API key (gws_...) — minted by exchanging your license JWT at POST /v1/account/api-keys. Used as a Bearer token on /v1/chat/completions and /v1/messages. Stored at rest as a SHA-256 hash; the raw key is shown to you exactly once at mint time and never recoverable.

We accept both Authorization: Bearer and x-api-key headers — the latter is what Anthropic SDKs (Claude Code) emit by default. Both paths route through the same hash check.

4. BYOK handling

When you route frontier-tier requests through the hosted gateway, your Anthropic / OpenAI / other-provider key is sent as a per-request HTTP header (x-modelmeld-byok-{provider}).

  • Keys flow into a request-scoped BYOKCredentials frozen dataclass at the route boundary (src/modelmeld/api/byok.py).
  • Per-request adapters are constructed via build_byok_adapters and share no client state with the long-lived adapters in the router.
  • The credential object is unreferenced when the request scope unwinds — no thread-local, no module-level cache, no async-context bleed.
  • The key is not written to persistent storage by the gateway.
  • Logging is designed to redact the key: the redactor preserves only the first 7 characters + length, never the secret bytes (see redact_for_log and _redact_key in src/modelmeld/api/byok.py). HTTP error responses pass any upstream-error text through a separate sanitizer (src/modelmeld/api/_safe_error_detail.py) that strips credential-shape substrings (Anthropic, OpenAI, AWS, GitHub, ModelMeld) before echoing to the client.
  • Provider names are validated against a frozenset allowlist (anthropic, openai); unknown providers are silently dropped to prevent adapter-inventory enumeration.

We test these properties in CI; if you discover a deviation, report it under §1.

5. Encryption

  • In transit: TLS 1.3 (with TLS 1.2 fallback) on modelmeld.ai (Vercel) and api.modelmeld.ai (Render). Hosting providers manage certificates.
  • At rest:Render's managed Postgres provides AES-256 encryption at rest for the full database volume and automated backups, managed via AWS KMS. We do not perform application-layer column-level encryption today; sensitive fields are stored as one-way SHA-256 hashes where the plaintext is not operationally required (API keys, prompt bodies).
  • Database access: connections from the gateway to Postgres use TLS, enforced at the Render configuration layer.

6. Data minimization

The hosted gateway is built on the OSS engine, which is designed to minimize what crosses the egress boundary and what gets persisted in the enterprise plane.

  • By default, prompt and completion bodies are not persisted. Per request, audit logs capture: timestamp, model, token counts, latency, cost, task category, and a SHA-256 hash of the prompt — not the prompt body. When optional features that require body retention (completion cache, tiered memory) are explicitly enabled, prompts and completions are stored according to the configuration you select.
  • Optional PII scrubber is available and, when enabled, applies pattern-based redaction to outbound text before cloud egress. Covered patterns currently include email addresses, US Social Security numbers, payment-card numbers (PAN shape), AWS access keys, Anthropic API keys (sk-ant-…), OpenAI legacy API keys (sk-…), GitHub classic personal-access tokens (ghp_…), GitHub fine-grained personal-access tokens (github_pat_…), and US phone numbers (src/modelmeld/privacy/scrubber.py). Text fields longer than 256 KB have only their first 256 KB scrubbed; the remainder is forwarded unscrubbed. Other GitHub token shapes (gho_, ghu_, ghs_, ghr_), Google / GCP credentials, Slack tokens, and OpenAI's newer sk-proj- / sk-svcacct- prefixes are not yet covered. Pattern-based redaction is best-effort defense in depth, not a guarantee; customers handling regulated data should implement their own upstream DLP controls.
  • Frontier keys transit per-request only (see §4).

7. Sub-processors

The hosted gateway depends on a small set of vendor services. Each receives a specific data subset under their own terms. The current list — and the data each receives — is in /privacy §4. We update the sub-processor list before adding any new vendor whose processing meaningfully changes the categories of data handled.

8. Supply-chain integrity

We treat the modelmeld PyPI package and OSS repo as part of the supply chain that downstream customers run.

Today

  • PyPI trusted publishing— releases flow through GitHub's OIDC trusted-publisher integration; no long-lived PyPI tokens exist on developer machines.
  • No source-level copying from third-party repos. All third-party patterns are re-implemented in-house. Dependencies are declared in pyproject.toml only.
  • Open-core boundary verifier runs in CI on every PR (see §9).
  • CVE scanning via pip-audit runs in CI; releases block on newly-disclosed CVEs in production dependencies.
  • Secret scanning via gitleaks on every push and PR.
  • CodeQL static analysis on every push.

Roadmap

  • Signed releases via cosign (keyless OIDC) — planned. Will publish verification command in each GitHub Release body when shipped.
  • CycloneDX SBOM per release — planned.
  • SHA-pinned GitHub Actions — planned. Currently version-pinned via Dependabot.

9. Open-core boundary

The split between the public AGPL modelmeld package and the proprietary modelmeld-enterprise control plane is enforced by scripts/verify_boundary.py in CI. The script enforces that no file under src/modelmeld/ imports from any modelmeld_enterprise.* module; a violation fails the build with a non-zero exit code. See docs/open-core-boundary.md for the full contract.

This matters because the open-core engine is what downstream customers pip install — boundary integrity prevents enterprise-only code or dependencies from leaking into the OSS distribution.

10. Audit logging (Hosted)

The hosted gateway writes append-only audit rows for every chat completion, with:

  • Prompt SHA-256 hash (not body)
  • Routed model and provider
  • Tier and task category
  • Token counts, latency, cost
  • Tenant ID and API key ID

Append-only enforcement: the application-role database user does not hold UPDATE or DELETE grants on the audit table. Schema-level constraints reject mutations outside the documented retention path. Audit-write privileges are separated from the read role used by billing views and the customer-facing usage dashboard.

Retention is 12 months per /privacy §5.

11. Production access

  • Production console access (Render, Vercel, Stripe, GitHub admin, database admin) is restricted to a small set of named engineers.
  • All production console surfaces require FIDO2 hardware-key MFA.
  • Production database is reachable only via Render's managed connection; no direct internet exposure.
  • All production console sessions are logged in the respective vendor's audit log.

12. Incident response

We maintain an internal IR runbook covering severity classification, escalation paths, communications plan, and post-mortem template. The runbook is exercised on a quarterly tabletop cadence.

If a confirmed incident affects customer data, we will notify affected customers via the email associated with their account within 72 hours of confirmation, consistent with the breach-notification posture in our DPA.

13. Secret rotation

We maintain a documented rotation schedule for production secrets, including license-signing keys, third-party webhook secrets, database administrator credentials, and our own upstream provider keys. Rotations are scheduled on a periodic basis with documented procedures for each secret class; any suspected compromise triggers immediate rotation outside the normal cadence.

Specific rotation intervals and procedures are available under NDA via security@modelmeld.ai as part of a vendor-due-diligence review.

14. Backup and recovery

  • Daily automated Postgres backupsvia Render's managed-database backup service.
  • Point-in-time recovery window: 7 days.
  • Restore test cadence: quarterly.
  • RTO target: 4 hours from confirmed data-loss incident to production restoration.
  • RPO target: 24 hours (the daily backup interval); reduced to ≤5 minutes within the PITR window.

15. Compliance posture

We are pre-SOC 2. SOC 2 Type 2 audit work is in progress. No SOC 2 report has been issued, and no representation of SOC 2 compliance should be inferred from this page.

Today we implement specific controls aligned with the SOC 2 Trust Services Criteria:

  • Change management via PR review + branch protection + CI gates (CC8)
  • Logical access control via FIDO2 MFA on all admin surfaces (CC6)
  • Continuous monitoring via Render's platform logs + GitHub audit log (CC7)
  • Vulnerability management via pip-audit CI step + Dependabot (CC7)
  • Vendor management via the documented sub-processor list (CC9)

GDPR / CCPA / CPRA: see /privacy §6.

HIPAA, FedRAMP, PCI DSS: not applicable. We are out of PCI scope (Stripe handles card collection), and we do not knowingly process PHI or government-classified data through the hosted service. We do not sign Business Associate Agreements at this time. If your use case requires one of these, ModelMeld in its current form is not the right fit.

16. Code transparency

The OSS engine that does most of the security-relevant work — authentication, license verification, BYOK handling, PII scrubbing, audit headers — is public, AGPL-3.0-or-later, and reviewable in github.com/modelmeld/modelmeld.

The proprietary modelmeld-enterprise plane handles billing, license issuance, the audit-log database, and SOC 2-aligned control wiring. We can share architecture diagrams and per-control evidence under NDA.

17. What we don't promise

Specifically, we do not promise:

  • Uptime SLA on the self-serve hosted tier (Enterprise contracts can include SLAs).
  • Scheduled penetration tests at customer-defined intervals (planned post-SOC 2).
  • Confidentiality from upstream providers:routed prompt content is visible to the upstream model provider (Anthropic, OpenAI, Fireworks, Together, OpenRouter) at the point of inference — no homomorphic encryption is in play. BYOK customers who route their own Anthropic key remain subject to Anthropic's published data-handling commitments for that traffic; ModelMeld is not in the data-controller position for BYOK-routed prompts.
  • Multi-region availability: today our hosted plane runs in US-East only. No data-residency guarantee outside the US.
  • Customer-managed encryption keys (CMEK) for the hosted plane.
  • On-prem or air-gapped deployment in the v1 hosted product. Self-host the OSS gateway if you need that.
  • Claims about whether upstream providers (Anthropic, OpenAI, etc.) train on routed traffic. Their published API ToS apply.

18. No warranty

This page describes our security practices as of the effective date and is provided for informational purposes. Nothing on this page creates a warranty, guarantee, or contractual commitment. Our binding obligations to customers are set forth solely in the Terms of Service and any executed order form or master services agreement. To the maximum extent permitted by law, the security practices described here are provided "as is" without warranty of any kind. Our aggregate liability for any claim arising from or relating to security is governed by, and subject to the limitations in, the Terms of Service.

19. Contact