Security & Compliance

This page describes the security and compliance posture of FoxNose today. We list what's in place, what's coming, and what's explicitly out of scope — including who FoxNose is not designed for. The goal is transparency: developers evaluating FoxNose can decide in two minutes whether it fits their constraints.

At a glance

CapabilityStatus
Per-tenant data isolation (by data model, not convention)✅ In place
Schema-validated API surface (typed filter operators only)✅ In place
Granular role-based access control✅ In place
Audit log (30-day retention)✅ In place
EU data residency✅ In place
GDPR mode (EU request processing)✅ Optional, per project
DPA (Data Processing Agreement)✅ Available on request
Sub-processors disclosure✅ Published
Two authentication models (Simple + Secure ECDSA P-256)✅ In place
US data residency zone⏳ Q3 2026
Extended audit log retention (90+ days)⏳ Q3 2026 (paid plans)
Penetration test report⏳ Q4 2026
SOC 2 Type 2❌ Not in scope today — target 2027
HIPAA BAA❌ Not in scope today
Conversational PII storage at scale❌ Not the product's shape

What's in place today

Per-tenant data isolation, by data model

Multi-tenancy on FoxNose is structural, not application-layer. Collections are the isolation boundary. A Flux API connects only the collections you grant it, and each collection connection carries its own allowed_methods set (get_one / get_many). A collection invisible to a Flux key over REST is invisible over MCP, too — there is no second permission surface to maintain. See Access Control.

Schema-validated API surface

The Flux query language exposes a fixed allowlist of filter operators: eq, ieq, gt, gte, lt, lte, in, iin, between, contains, icontains, startswith, endswith, includes, exists, null, plus a not_<op> negation prefix. There is no raw query escape hatch — clients cannot inject SQL, Cypher, or arbitrary query DSL through the API. See Search & Filtering.

Authentication

Three authentication models — used independently per surface:

  • JWT for human users via the dashboard or Management API.
  • Simple Key (Authorization: Simple <public>:<secret>) — a static key pair for MCP clients and any integration that can only send static headers.
  • Secure Key (Authorization: Secure <public>:<signature>) — per-request ECDSA P-256 signatures for server-side and SDK integrations.

See Management API Authentication and Flux API Authentication.

Granular role-based access control

Roles are scoped at four granularities: organization, project, environment, or a custom set of permissions across content management, environment management, Management API resources, and Flux API resources. The "Granular Role" type is recommended for automation, CI/CD, and partner access. See Access Control.

Audit log

All content changes — create, update, delete — produce immutable event records. Retention is 30 days at the current tier. Logs capture actor, action, entity, timestamp, IP address, and request origin. Request and response bodies are never stored. Audit data is automatically scoped to what the caller has permission to read. See Access Control and the Events API reference.

EU data residency and GDPR mode

Core operational data (organization metadata, user accounts, backups) is always stored exclusively within the EU. Project data follows the storage zone you pick at project creation — currently EU only. Projects in the EU zone may enable GDPR mode, which additionally guarantees that all request processing happens within the EU. See Data Residency.

DPA and sub-processors

A Data Processing Agreement is available on request. Our sub-processors are listed publicly.

In progress

These items are tracked on the public roadmap and timed against customer demand:

  • US data residency zone — Q3 2026. Until then, project data is EU-only.
  • Extended audit log retention (90+ days, configurable) — Q3 2026, available on paid plans.
  • Independent penetration test report — Q4 2026.

Not in scope today

This is the section to read carefully. The fastest way to lose trust in a dev tool is to discover a gap after you've built around it. We list every meaningful gap we know about so you can rule FoxNose in or out before you start.

No SOC 2 certification

We do not have a SOC 2 Type 1 or Type 2 audit. The target is 2027, and it will be triggered by paying customer demand rather than aspirational marketing. If your procurement process requires SOC 2 as a hard prerequisite, FoxNose is not for you today — come back when our enterprise tier ships, or start a conversation about timeline.

No HIPAA BAA

FoxNose does not offer a HIPAA Business Associate Agreement. We are not designed for PHI today. If you need to store or process protected health information, FoxNose is not the right backend for that data class.

Not designed for PII at scale

FoxNose is built for the knowledge your AI agent reads from — product catalogs, FAQs, help articles, ticket and policy data, internal documents. It is not designed for storing user conversation history or personal preference profiles. If your use case is "remember things about each user across sessions", you want a memory layer — see mem0 or Zep, which are designed for that shape of data. FoxNose intentionally does not occupy that slot.

Not for regulated workloads

Until our enterprise tier ships:

  • Healthcare PHI — not in scope.
  • Payment card data (PCI DSS) — not in scope.
  • Government-classified content — not in scope.

These will be addressed as part of the SOC 2 / enterprise track.

Who FoxNose is for

FoxNose fits best for:

  • Seed and Series-A AI startups building vertical agents (customer support, e-commerce, internal ops, legal, healthcare admin) where the data is the business's operational content, not user PII.
  • Independent developers and small teams evaluating agent backends with self-serve procurement.
  • AI agencies building agents for multiple clients, where multi-tenant isolation is the core requirement.

FoxNose is not the right fit for:

  • Enterprise procurement requiring SOC 2 or HIPAA today.
  • Products that store user PII or conversational data at scale.
  • Regulated workloads in healthcare, finance, or government today.

Reporting a security issue

Email security@foxnose.net with details, repro steps, and your contact information. We aim to acknowledge reports within one business day. We do not offer a formal bug bounty program today, but we recognize researchers in our release notes.

For data-processing or compliance questions specifically, contact compliance@foxnose.net. For general support, support@foxnose.net.

Related

Was this page helpful?