Security and trust

Deployment model

What leaves the instance and what does not

The honest answer has two parts: what the product does on its own, and what it does when an operator points it at something.

Each of those destinations is a decision the operator makes and controls. The instance does not add a destination of its own.

Identity and access

Evidence and auditability

Release integrity

Dependency and secret hygiene

Vulnerability disclosure

Continuity

Security questionnaire answers

These are the answers to the questions that recur in a vendor security review. Each answer describes the self-hosted product as it ships, not a hosted service.

What is the deployment model, and is the product multi-tenant?

Self-hosted. You run the application, database and queue on infrastructure you choose, including an air-gapped network. Farnalabs does not host an instance and has no access to yours. One instance can serve several organisations, and each organisation is isolated by row-level security in Postgres. A single-organisation deployment is the common case.

Where is customer data stored, and in which region?

In your database, in the region and on the infrastructure you choose. Farnalabs receives no copy, so there is no Farnalabs region or data centre to declare. If you configure a third-party model backend, prompts travel to that backend and its residency terms apply to those calls.

What data does Farnalabs receive from a running instance?

Not by default. There is no telemetry, no usage reporting and no call-home licence check unless an operator turns it on. An operator can optionally enable aggregate product analytics, which posts usage counters (never run data, prompts, outputs or credentials) to a vendor endpoint they configure, and it requires both an instance-level switch and per-organisation consent. With it off, which is the default, the instance makes no outbound call to us. Run data, prompts, outputs and credentials stay in your instance. The licence key is verified locally against a public key, so activating or renewing Team does not make the instance contact us.

Which subprocessors do you use?

None for the self-hosted product. Farnalabs processes no data from your instance, and no Farnalabs subprocessor sits in the path of a run. Data leaves your instance only towards destinations you configure: model backends, connectors, notification endpoints and a hosted execution environment if you enable one. Each of those is your choice and your contract. The separate opt-in community library is the only service Farnalabs operates that processes submitted content, and its subprocessors are listed in its Data Processing Agreement.

Will you sign a Data Processing Agreement?

There is no DPA for instance data, because Farnalabs does not process it. You control the instance and the data in it. The opt-in community library is a separate service that does process submitted content, and its Data Processing Agreement covers that processing.

How is data encrypted in transit and at rest?

In transit, Modulo serves HTTP and expects you to terminate TLS at your reverse proxy, load balancer or ingress. Postgres connections support TLS through sslmode in DATABASE_URL, and the application rejects the prefer and allow values because they can silently downgrade to plaintext. Redis can use TLS through a rediss:// URL. At rest, connector credentials, model backend API keys, MCP server credentials, webhook and notification secrets, entries in the secrets table and agent checkpoints are encrypted in the database with Fernet (AES-128-CBC with HMAC-SHA256) using FERNET_KEY. The application refuses to start without SECRET_KEY and FERNET_KEY. Run inputs, run outputs and the audit chain are stored in your database without application-level encryption, so disk or volume encryption is your control.

Which authentication methods are supported?

Local accounts with passwords configured by the operator, OIDC or SAML 2.0 single sign-on against your identity provider, and SCIM 2.0 provisioning from that directory. SSO and SCIM are Team-tier features.

What authorisation model is used, and how is tenant data isolated?

Organisation roles: viewer, runner, operator and admin. A user's team role is capped by their organisation role. On Postgres, row-level security is enabled on every organisation-scoped table, and the application connects as a non-owner database role without BYPASSRLS. A small set of tables that exist before an organisation context (organisations and invitations), and system-administration paths, are outside RLS by design. An instance can hold several organisations with separate data. Team-scoped role-based access control is a Team-tier feature.

What does the audit log record, can it be altered, and how is it exported?

Sign-ins, permission changes, approvals, configuration changes, run starts, agent dispatches and gate outcomes are recorded. Every entry carries a SHA-256 hash over its own content and the hash of the entry before it, and the audit table is append-only: triggers reject UPDATE and DELETE. Each organisation has its own chain. The audit viewer, the export endpoint, the chain scan and the signed evidence pack for offline verification are Team-tier features. The paginated audit-list API, GET /api/v1/admin/audit, is not feature-gated, so an administrator on the Community tier can still read audit events over the API. Farnalabs holds no copy, and retention is whatever your database and backups keep.

How do you handle vulnerability reports?

Report to [email protected] or through GitHub's private vulnerability reporting. SECURITY.md sets out the policy, supported versions and what to include. Reports are acknowledged within 48 hours, triage follows within 7 days, and disclosure is coordinated on a 90-day window, or sooner when a fix is available. The machine-readable contact is published at /.well-known/security.txt. There is no bug bounty programme.

Which secure development practices run in CI?

bandit, semgrep and gitleaks run in pre-commit and again in CI. CI also runs pip-audit against Python dependencies, Trivy against dependency CVEs and misconfigurations, SonarCloud static analysis, and a pnpm audit gate at critical severity for frontend dependencies. OWASP ZAP DAST runs nightly against staging, and mutation testing runs weekly.

Which compliance attestations and certifications do you hold?

None. There is no SOC 2 report, no ISO 27001 certificate, no published penetration test report, no named Data Protection Officer and no uptime SLA. The running system is your instance, so an attestation over Farnalabs' environment would not describe the system your auditor assesses. The audit chain and its export are the evidence you can give an auditor.

What backup, disaster recovery and business continuity commitments apply?

These are your controls, because the instance is yours. Modulo ships backup and restore tooling: an encrypted archive script that dumps Postgres, collects the key material and encrypts the archive with AES-256-CBC, and a directory-based backup command that writes unencrypted output. Scheduling backups, encrypting anything written unencrypted, storing copies off-site and testing restores are operator responsibilities. Farnalabs holds no copy of your data and cannot restore it for you.

What incident response and notification commitments do you offer?

There is no formal incident response SLA and no contractual notification window for self-hosted customers. Security reports are acknowledged within 48 hours through the disclosure process, and the coordinated disclosure timeline in SECURITY.md applies to vulnerabilities in the software. Incidents inside your instance are yours to detect, contain and notify on, because the logs and the data are yours.