Zero-Trust Security

The multi-layered defense architecture protecting the Logic Mesh

In an ecosystem where AI agents freely communicate and execute math on remote servers autonomously, traditional perimeter security (VPNs, IP Whitelisting, Passwords) is completely insufficient.

The Logic-Injection-on-Origin Protocol (LIOP) assumes the network is inherently hostile, embracing an Enterprise Zero-Trust Architecture.

Every layer of LIOP, from transport to execution, integrates defense-in-depth cryptographic and runtime isolation boundaries.

The Shield: Six-Layer Zero-Trust Security Pipeline

1. Transport Encryption (Noise & PQC)

Instead of relying on centralized Certificate Authorities (like TLS/HTTPS), LIOP utilizes the Noise Protocol Framework, reinforced with Post-Quantum Cryptography:

• Ed25519 Identities: Every Agent and Server generates an Ed25519 keypair. Your Public Key is your Peer ID on the internet.
• Mutual Authentication: Connections in the Kademlia Mesh are mutually authenticated upon handshake. Both peers establish cryptographic proof of identity.
• Post-Quantum Key Agreement (ML-KEM-768): Handshakes utilize Kyber768 (ML-KEM-768) to derive the symmetric key for AES-256-GCM payload encapsulation, shielding logic transmission from “Harvest Now, Decrypt Later” quantum attacks.
• Post-Quantum Digital Signatures (ML-DSA-65): Manifests, capabilities, and revocation commitments are sealed with Dilithium65 (ML-DSA-65).
• 1-Hour Strict Session Lifetime: Derived symmetric keys expire after 3600 seconds to minimize exposure windows and mitigate replay attacks.
• Mutual TLS with CertManager: Supports enterprise X.509 client authentication with zero-downtime certificate hot-reloading.

2. Payload Inspection (Static Guardian & Taint Analyzer)

Before the Data Node permits execution of the injected code, the payload undergoes static Abstract Syntax Tree (AST) analysis at both binary and script levels.

The Guardian Module inspects the WebAssembly Abstract Syntax Tree (AST). Since WebAssembly is strongly typed and verifiable without execution, the LIOP Server validates that the binary contains no malformed instructions, unconstrained recursive branching, or unauthorized host system imports.

For interpreted scripts (such as JavaScript payloads), the Taint Analyzer executes a static Information Flow Control (IFC) check. This tracker inspects the AST to ensure PII variables do not leak into scalar outputs.

Generator & Iterator Evasion Protection: To prevent bypass attempts that use generators or iterators (function* / yield) to extract records without triggering standard property checks, the Taint Analyzer performs deep static traversal of function scopes:

• YieldExpression Tracking: The engine recursively evaluates yield arguments, ensuring PII-derived values are flagged even when encapsulated in generator yields.
• Function/Generator Scope Tainting: Local functions (FunctionDeclaration, FunctionExpression, ArrowFunctionExpression) that return or yield tainted fields are marked as tainted.
• Iterator Method Chains: When a tainted function is invoked (gen()), its resulting iterator and subsequent operations (like .next().value) are flagged, transferring the taint dynamically through the expression tree and neutralizing generator-based exfiltration.

This neutralizes evasive patterns and unauthorized host access statically before execution commences.

3. Anti-Exfiltration (Egress Filter)

If an injected module attempts unauthorized data emission outside sandbox bounds, the LIOP Server enforces a Layer 3 Egress Filter before transmitting the response across the transport pipeline.

This filter analyzes the output buffer (checking for Personally Identifiable Information, API keys, or restricted schema patterns like patientId). If privacy violations are detected, the response is blocked and the payload dropped.

Double JSON Encoding Defense (Deep-Parsing Recursion): AI Agents may attempt to bypass static pattern matching by double-serializing strings ("\"id\":\"...\""). To counteract this, the PiiScanner implements recursive deep-parsing. If a returned string resembles an object, the filter deserializes it internally to expose the underlying schema before applying matching rules, preventing nested serialization evasion.

Aggregation-First Policy: Beyond PII scanning, the Egress Filter enforces an Aggregation-First heuristic that blocks raw row-level data exports. If the sandbox output contains arrays with more object elements than the configured threshold (default: 10), the response is rejected. Only aggregated results (counts, averages, summaries) pass through, preventing bulk data exfiltration even when individual records contain no PII.

Cryptographic & Transport Wrapper Unwrapping: To prevent false positive triggers caused by HMAC-SHA256 ZK-Receipt signatures, JSON-RPC envelopes, or gRPC proxied tool responses (such as { content: [{ type: "text", text: "..." }] }), the Egress Shield executes its scan strictly over the unwrapped business data (via unwrapForAggregationPolicyScan). This ensures that cryptographic seals and routing wrappers do not interfere with safety policies.

Conditional Error Opacity: In production environments (NODE_ENV=production), all Egress violations return a generic [LIOP] Egress Security Violation message with zero internal details. In development/test environments, detailed schema validation errors and corrective hints are exposed to enable rapid iteration and LLM self-correction.

4. Sandboxing (WASI)

As detailed in the WASI Sandboxing chapter, the execution layer is fundamentally isolated by the CPU restrictions imposed by the bytecode runtime, ensuring zero unauthorized I/O or network escalation.

5. Hardware Isolation and Remote Attestation (TEEs)

Software isolation is never complete against advanced persistent threats (APT) leveraging hypervisor bypasses or zero-day kernel exploits. LIOP integrates native hardware isolation with pre-flight cryptographic attestation for Trusted Execution Environments (TEEs) such as AMD SEV-SNP and AWS Nitro Enclaves.

Before injecting any computational module into a confidential enclave, the client or gateway router executes verifyTeeAttestationDetailed:

• AMD SEV-SNP Reports: Validates binary attestation reports of 1,184 bytes, verifying hardware signature validity and asserting that the REPORT_DATA field at byte offset 0x50 strictly binds to SHA-256(publicKey || nonce).
• AWS Nitro Enclaves: Parses COSE_Sign1 documents, validating platform measurement registers (PCR0, PCR1, PCR2) and confirming that the enclave public key is embedded in user_data.
• Synthetic Enclaves: Permits prefixed TEES envelopes strictly within development environments.

This ensures that neither cloud infrastructure operators nor compromised host operating system administrators can read memory, extract keys, or mutate datasets during execution.

6. Computational Integrity (ZK-VM and Post-Quantum Hybrid Receipts)

In decentralized agent workflows, clients must verify that remote data nodes executed the requested logic honestly without adulterating inputs or fabricating responses. LIOP resolves this through a tri-modal zero-knowledge proof architecture:

1. Mode 0 (HMAC_LEGACY, 0x00): Symmetric lightweight commitment derived from the ML-KEM-768 session secret. Delivers sub-millisecond execution ($< 0.05\text{ ms}$) with minimal compute overhead, designed for battery-constrained edge IoT devices.
2. Mode 2 (GROTH16, 0x02): Zero-knowledge succinct non-interactive proof over the BN254 elliptic curve paired with a canonical 144-byte immutable binary journal. Provides compact 252-byte proofs verifiable directly on EVM smart contracts (ecPairing precompile) at low gas costs ($~200,000\text{ gas}$).
3. Mode 3 (GROTH16_PQC_HYBRID, 0x03): Quantum-resistant hybrid receipt combining the Groth16 BN254 proof with an ML-DSA-65 post-quantum digital signature (NIST FIPS 204) of 3,309 bytes over SHA-256(journal || proof). This mode is mandatory for Clearance Tier 1 enclaves (banking, medical vaults), ensuring computational proofs cannot be forged even after classical elliptic curves are broken by Shor’s algorithm.

The protocol also incorporates the SP1 zkVM Guest Scaffold (crates/liop-sp1-guest), compiling a deterministic WebAssembly runtime (wasmi) to the riscv32im-succinct-zkvm-elf architecture to facilitate universal STARK-based execution proofs.

Dataset Integrity Anchor: Each ZK-Receipt embeds a dataset_digest (a SHA-256 digest of the underlying dataset at execution time). This cryptographic anchor allows clients to verify that the dataset was identical across consecutive queries, definitively separating legitimate Differential Privacy noise from unauthorized data mutation.

The ZK Shield Proxy: Cryptographic receipt validation (verifyZkReceipt) is executed off the main event loop using worker threads (zk-verifier.ts). Capabilities marked with zkMode: "required" (PROOF_MODE_ZK_BLOCKING) reject any missing or invalid proof deterministically, preventing cipher-suite downgrade attacks.

7. Differential Privacy Engine (Laplace Mechanism)

When the WASI sandbox executes injected logic on small datasets (below the configurable smallDatasetThreshold, default: 50 records), raw numeric outputs could reveal individual-level information through differencing attacks (running the same query before and after adding a record) or binary search attacks (iterating filter thresholds to isolate a single record).

LIOP mitigates this with a calibrated Laplace Mechanism that injects mathematically bounded noise into all numeric output fields before egress.

CSPRNG Noise Source

All noise is generated using crypto.randomBytes() from the Node.js crypto module (backed by the OS-level entropy pool), never Math.random(). This prevents state-reconstruction attacks where an adversary could predict future noise values by observing 3-5 noisy outputs, as mandated by NIST SP 800-226.

Deterministic Audit Mode (DDP)

For SOX/PCI-DSS audit scenarios requiring reproducible ZK-Receipts, the engine supports Deterministic Differential Privacy (DDP). When activated, the Laplace noise generator initializes a SHA-256-based PRNG seeded with dataset_hash + image_id, producing identical noise for identical queries on immutable datasets. This restores full ZK-Receipt verifiability without violating the mathematical privacy guarantee, because the seed remains cryptographically unpredictable to external observers who lack access to both the dataset and the exact injected logic.

Query-Aware Sensitivity

Instead of applying a single global sensitivity to all output fields, the engine automatically detects the query type from the field name:

Query Type	Key Pattern	Sensitivity	Rationale
COUNT	count, length, size, num, total_records	Always 1	Adding/removing one record changes count by at most 1
AVERAGE	avg, mean, average	globalSensitivity / n	Bounded contribution per record
SUM	Any other numeric key	globalSensitivity	Operator-configured max plausible value

This mirrors Google’s Differential Privacy library architecture, which uses separate CountParams, SumParams, and MeanParams, each with independent sensitivity calibration.

Epsilon Floor

For datasets with fewer than 10 records, the engine enforces a minimum epsilon of 1.0, regardless of the operator’s configuration. This prevents catastrophic utility destruction where noise completely overwhelms the signal. Apple’s most sensitive category (Health Data) uses ε=2.0 on millions of records; using ε < 1.0 on tiny datasets produces mathematically meaningless results.

Post-Processing Invariants

Following the US Census 2020 TopDown Algorithm, the engine enforces two post-processing constraints that are free under the DP post-processing theorem (they do not consume additional privacy budget):

1. Non-negative integers: All count fields are rounded and clamped to ≥ 0.
2. Type preservation: Integer inputs produce integer outputs; non-negative inputs remain non-negative.

8. Tiered Query Budget (NIST SP 800-226)

Even with Differential Privacy, an adversary could theoretically bypass Laplace noise protections by executing the same query thousands of times across the mesh and computing the statistical average to reconstruct the original data.

To prevent this differential reconstruction, LIOP implements a Tiered Query Budget Engine aligned with NIST SP 800-226 guidelines.

Client-Isolated & Session-Persistent Budgets

• Session Isolation & Persistence (Anti-Bypass): Budgets are tracked per-client using the cryptographic identity (agentDid derived from their persistent Ed25519 PeerID, or clientId from JWT tokens authorized by the Nexus OAuth 2.1 server) verified during the PQC handshake (negotiateIntent). Under the hood, these budgets can be written to disk via a shared JSON file (budgetStorePath). This prevents limits from being bypassed by reconnecting, starting a new gRPC intent, or restarting the server, as the budget is anchored to the persistent cryptographic client ID rather than ephemeral transport tokens (such as gRPC session_token).
• Concurrency & File Locking: To prevent statistical differentiation attacks where multiple parallel requests are dispatched concurrently to bypass budget limits, the engine synchronizes access using file-level locking (.lock files). Updates are atomic, guaranteeing that no two client-specific requests can evade validation checks in a distributed or multi-threaded setup.
• Preflight Enforcement: The TaintAnalyzer decodes and scans the AST of the injected logic before spawning the sandbox. It extracts all accessed fields, including those within generator loops or direct indices. If a field’s cumulative query count (loaded dynamically from the budget store) exceeds its tier limit, the request is instantly aborted in preflight, returning a clean error directly to the LLM.
• Fail-Safe Fallback: If filesystem restrictions or deadlocks prevent locking/writing, the engine prints a warning and falls back dynamically to in-memory session budget tracking, maintaining security enforcement at all times.

Sensitivity Tiers

LIOP classifies fields into three distinct sensitivity tiers, applying different query budgets per session:

Sensitivity Tier	Target Fields	Query Limit / Session	Description & Rationale
FORBIDDEN (Tier 3)	SSN, password, full name, email, credentials	3 queries	Direct identifiers. Highly restricted, blocked after 3 requests.
SENSITIVE (Tier 2)	Account balance, account type, medical diagnosis	8 queries	Domain-critical properties. Semi-restricted to prevent inference.
PUBLIC (Tier 1)	Age, transaction currency, price, metadata	25 queries	Low-sensitivity fields. Standard limit.

Note: For legacy compatibility, a uniform limit can be configured via queryBudgetPerField, which overrides the tiers and enforces a single limit for all fields.

9. Privacy Threat Modeling Alignment (LINDDUN & PLOT4ai)

To guarantee industrial and regulatory compliance (e.g., GDPR, HIPAA, EU AI Act), the Logic-Injection-on-Origin Protocol’s security controls are systematically aligned with standard privacy threat modeling frameworks.

LINDDUN Mapping

LIOP mathematically and structurally mitigates all seven threat categories of the LINDDUN framework:

• Linkability (L) & Identifiability (I): Neutralized by the calibrated Laplace Differential Privacy Engine that perturbs numeric outputs, an AST-level Taint Analyzer that flags character-level exfiltration, and a hard K-Anonymity threshold ($n < 10$) that blocks outputs in tiny datasets.
• Non-repudiation (N): Solved through ZK-Receipts (HMAC-SHA256 commitments and cryptographic execution receipts) coupled with sovereign Ed25519 node identity signatures, ensuring verifiable computational proof.
• Detectability (D): Defeated by normalizing CPU/fuel consumption metrics into discrete buckets of 100 and utilizing a CSPRNG (crypto.randomBytes()) for Laplace noise, preventing timing and state-reconstruction side-channel attacks.
• Data Disclosure (D): Structurally prevented by the core Logic-on-Origin paradigm (pushing math instead of pulling data), backed by the multi-layered Egress PII Shield and the Aggregation-First Policy that blocks raw row exports.
• Unawareness (U) & Non-compliance (N): Addressed via dynamic schema instructions (liop://schema/guidelines) that inform AI agents of active constraints, built natively to comply with NIST SP 800-226 and OWASP DLP 2025 guidelines.

PLOT4ai Alignment

For AI-centric risks, LIOP maps directly to the core domains of PLOT4ai (Privacy Library Of Threats for AI):

• Data & Data Governance: Enforced by sovereign Kademlia DHT peer routing; data remains local, secure, and under the origin’s sole administrative domain.
• Cybersecurity & Safety: Guaranteed by the WASI Sandbox running with pre-execution frozen prototypes (PCI-DSS compliant) and transport-layer Post-Quantum Cryptography (ML-KEM-768 handshakes).
• Accountability & Transparency: Provided by deterministic audit modes (DDP) and cryptographic verification of WASM image hashes inside Trusted Execution Environments (TEEs).