Security posture

This page is the long-form security view, written for vendor security questionnaires and lender-side technical advisors. We are seed-stage and honest about what is shipping today, what is in design, and what is on the formal-audit roadmap.

Deployment posture

Every pilot runs as a customer-isolated deployment by default. There is no shared multi-tenant data path. The runtime can be deployed inside the buyer's own cloud account (customer-VPC) or inside a dedicated Felixfusion account whose data plane is provisioned per engagement.

When deployed inside the buyer's VPC, no source documents, derived artifacts, or audit logs leave that account. The buyer holds the keys, the buyer holds the logs, and the buyer can revoke access without our involvement.

Encryption + key management

TLS 1.2 or higher for every network path the runtime touches. AES-256 for at-rest encryption on every storage primitive (object store, document database, audit log).

Key management is delegated to the cloud provider's KMS. Customer-managed keys (CMK) are supported in scoped deployments where the buyer's procurement, security, or legal team requires it. Key-handoff is documented per engagement.

Isolation + tenancy

Each pilot runs in its own sandboxed execution context. There is no shared state between pilots, no cross-tenant data paths, and no shared model-fine-tuning surface that could leak private content from one engagement into another.

Agent workers carry per-engagement credentials issued at runtime. Credentials are short-lived and rotated automatically. Long-lived shared credentials are not used.

Audit log + provenance

Every agent generation, every human review, every approval, every revision is written to an append-only audit log. The log is exportable on request in a structured format suitable for an external review.

Every agent claim is provenanced. A reviewer can open any sentence in any draft and trace it back to the specific page, table, or row in the source material. We are not running an opaque-embedding stack.

Governance + human gates

No agent output leaves the system without a human approval. Every external artifact (DD pack, IC memo, compliance brief, redline, award memo) is generated as a draft, flagged for review, and held until a senior-analyst or procurement-lead signature lands.

The review interface shows the draft alongside the source trail. Approving is a signed event. Rejecting routes back to the generating agent with structured feedback, not free-form prompt drift.

Compliance + frameworks

Design informed by NIST 800-53 (Rev 5), SOC 2 Type II, and ISO 27001 controls. We are not SOC 2 certified today; formal audit is on our 2027 roadmap and we will publish the attestation when it lands.

For energy-procurement scopes Nexus carries operational awareness of UFLPA (Uyghur Forced Labor Prevention Act), IEC 62933 / UL 9540 / NFPA 855 (BESS), IEC 61215 / IEC 61400 (solar / wind), and ICV (in-country value) rule sets. These are runtime concerns, not security frameworks, but they sit inside the same governance envelope.

Data residency + retention

Default data residency is the buyer's region. We do not move source documents or derived artifacts across regions without an explicit consent record per engagement.

Default retention is the engagement window plus an agreed audit-readiness tail (typically 12 months). Earlier deletion is supported on request. Right to export is unconditional.

Subprocessors

The runtime relies on a short, named subprocessor list: cloud infrastructure, model providers, and observability. The current list is provided per pilot during the security questionnaire phase. Changes to the list are notified in advance, not after the fact.