SECURITY ARCHITECTURE FORMAL SPECIFICATION

Nyx Security Limits & Formal Guarantees

A precise, mathematically verified breakdown of what Nyx guarantees by default, what is enabled via opt-in flags, and what remains outside the scope of a general-purpose programming language.

🛡️ The Security Ground Truth

Modern security breaches like RUSTYSHADE prove that memory safety does not prevent malware; memory safety merely ensures the software runs without memory errors. Nyx takes an honest approach: the language cannot stop malicious intent, but it gives defenders provable tools (SBOMs, SMT proofs, linear capabilities, and kernel sandboxes) to mathematically audit and isolate untrusted software.

✅ What Nyx Guarantees

1. Zero Spatial & Temporal Memory Corruption

Enforced statically via the Region Inference Engine. Buffer overflows, use-after-free, double-free, and dangling pointer dereferences are mathematically impossible in safe Nyx code, with 0.00ms GC pause jitter.

2. Linear Capability Membranes (Havilah)

Files written with .hav enforce linear token tracking. Privileged capabilities (CAP_NET, CAP_FILE, CAP_SPAWN) cannot be duplicated, leaked, or forged by untrusted sub-modules.

3. Machine-Checkable Invariants (Jude)

Code verified with .jude discharges mathematical proof obligations against the Z3 SMT solver. Declared invariants (e.g. robotic torque bounds or array monotonicity) hold across 100% of inputs.

4. OS Kernel Sandboxing (Opt-In)

When executed via nyx run --sandbox=policy.toml, the OS kernel (Landlock/Seccomp on Linux, AppContainer on Windows) strictly restricts file paths, network interfaces, and child processes.

5. Cryptographic Provenance & SBOM (Opt-In)

Compiling with nyxc build --emit-sbom attaches signed CycloneDX 1.5 sidecar manifests recording dependency hashes and static capability usage.

⚠️ What Nyx Does NOT Guarantee

1. Developer Logic & Intent Correctness

Memory safety prevents memory corruption bugs; it does not prevent logic bugs. A function that calculates incorrect financial interest or misinterprets sensor telemetry is memory-safe but logically incorrect.

2. Prevention of Malicious Software Creation

Any general-purpose language with HTTP and file I/O capabilities can be used to write malware. Nyx empowers defenders to detect and isolate threats; it does not restrict the general-purpose power of the compiler.

3. Automatic Supply-Chain Immunity

Importing an untrusted third-party package without auditing will execute with host permissions unless the application is explicitly wrapped in a capability sandbox or verified with Jude certificates.

4. Side-Channel Resistance by Default

Timing attacks and cache side-channels require constant-time programming discipline (supported via std.crypto).

5. Raw C FFI Memory Safety

Calling unsafe external C libraries via extern "C" bypasses Nyx's safe memory inference. FFI boundaries must be audited independently.

2. Opt-In Security CLI Flags

In accordance with Nyx's zero-overhead design, all advanced security features are opt-in:

# 1. Emit Cryptographic SBOM & Provenance
nyxc build main.nyx --emit-sbom --sbom-key ./keys/prod.key

# 2. Emit Jude Mathematical Proof Certificates
nyxc build telemetry.nyx --verify --emit-certificates

# 3. Execute Inside Kernel Capability Sandbox
nyx run --sandbox=strict_policy.toml ./main.nyx

3. Explore Further

🔍 Living Abuse Patterns & Defense Registry → 🛡️ 2026 Security Penetration Audit →