This document describes the security posture NovaQuantiX applies to every engagement and to the operation of the website novaquantix.tech. It is meant for security teams reviewing our practice before signing an SOW, and for researchers wishing to report a vulnerability.
1 · Engineering principles
- Memory-safe by default. Performance-critical paths are written in Rust. Low-level paths use C with sanitisers in CI. TypeScript and Python are used for application logic and training pipelines respectively.
- No secrets in source. Every secret is injected at runtime via environment variables or a secret manager. Repositories are scanned in CI with truffleHog and Gitleaks before any merge.
- Least privilege. Every cloud, Git, and third-party account uses the minimum scope required. Permissions are reviewed quarterly.
- Reproducible builds. Pinned dependencies, locked toolchains, deterministic compilation flags. Builds re-run from a tag must match byte-for-byte (where the language allows it).
2 · Signed releases (Ed25519)
Every release artifact is signed with an Ed25519 key whose public part is published in the Deliverable and pinned in the runbook. The signature covers a manifest of file hashes (SHA-256 / BLAKE3) and the build metadata (commit, toolchain, timestamp).
Verification can be performed with the included nova verify command or any standard Ed25519 verifier (e.g. signify, minisign).
3 · Merkle-chained audit logs
Build and deployment events are written to an append-only log whose entries form a Merkle chain. Each entry contains the previous root, making any retroactive tampering detectable.
Audit logs are part of the Deliverable. Clients can verify the root independently and check the integrity of any historical event.
4 · Secret management
- Production secrets are stored in client-controlled secret managers (Vault, AWS Secrets Manager, Azure Key Vault, Doppler, or equivalent). NovaQuantiX never holds production secrets after handover.
- During an engagement, working secrets are scoped to a per-project environment, encrypted at rest, and rotated at the end of the engagement.
- Sub-processor API keys (e.g. NVIDIA NIM, Cal.com, Moonshot, Vercel) are rotated on a documented schedule and immediately after any known exposure or staff change.
5 · Runtime isolation
- MCP servers and agent runtimes run in dedicated containers or sandboxed processes, with network egress restricted to the explicit allow-list documented in the SOW.
- Tool invocations are bound by per-tool budgets (token, time, call count) and a deterministic kill-switch reachable from the orchestrator.
- Human-in-the-loop checkpoints are mandatory for any write-side tool that affects production data, unless the SOW explicitly waives this for a low-risk path.
6 · Supply chain
- Direct and transitive dependencies are pinned in lockfiles. Updates are reviewed and tested against the Inspect-AI evaluation suite before merge.
- High-risk packages are vendored or replaced when feasible. Container base images are pinned to digest, not tag.
- Software Bill of Materials (SBOM) in CycloneDX format is delivered alongside every signed release.
7 · Data protection in transit and at rest
- HTTPS / TLS 1.3 with modern cipher suites on every endpoint.
- Database connections enforce TLS with mutual authentication where the engine allows it.
- Sensitive fields are encrypted with AES-256-GCM using keys held in the client's secret manager, never in the application.
- Backups are encrypted with a separate key and stored in a region aligned with the data-residency requirements documented in the SOW.
8 · Vulnerability disclosure
We welcome reports from security researchers. Please send your report to security@novaquantix.tech with as much detail as you can share. Encrypt sensitive details with our PGP key (fingerprint available on request).
- Acknowledgement: within 2 business days.
- Triage: initial impact assessment within 7 business days.
- Remediation: a fix or workaround is issued for high-severity issues within 30 days, lower-severity within 90 days.
- Credit: we publicly thank researchers who follow this responsible disclosure process and provide actionable reports.
Do not perform tests that disrupt our services or affect users other than test accounts you own. Do not access, modify, or download data that is not yours.
9 · Incident response
- Detect. Monitoring is wired to alerting channels covering availability, error rate, latency, anomalous tool calls, and authentication failures.
- Contain. The on-call engineer can isolate any affected component within minutes using documented kill-switches and feature flags.
- Eradicate & recover. Root cause is investigated, a patch is shipped through the standard signed-build pipeline, and services are restored.
- Communicate. Affected clients are notified within 24 hours of confirmed impact, in writing, with a preliminary assessment.
- Post-mortem. A blameless post-mortem is shared with affected clients within 7 business days, including timeline, impact, root cause, and corrective actions.
10 · Compliance
- GDPR (Regulation (EU) 2016/679) — see Privacy Policy.
- Cyber-resilience principles aligned with NIST CSF 2.0 categories (Identify, Protect, Detect, Respond, Recover).
- OWASP ASVS L2 baseline applied to web surfaces.
- EU AI Act — risk-based assessment performed for every engagement involving an AI system intended for production deployment.
11 · Contact
Security reports: security@novaquantix.tech. General security questions: contact@novaquantix.tech.