ID
NZID
Every user, browser, service, node, and gateway can be addressed by a cryptographic NovaZel Identity instead of only a changing IP address.
NovaZel Protocol · Identity-first flows · Built by Rocheston
Identity-first.
Policy-bound.
Quantum-safe.
NovaZel is a smart overlay network — identity, policy, and quantum-safe encryption running above TCP/IP. Every flow is verified. Every session is governed. Every connection is evidenced.
6Protocol layers
PQQuantum-safe
0Default trust
∞Identity flows
What it is
A protocol layer for verified applications, not just reachable addresses.
NovaZel sits above the existing internet and gives applications a stronger connection model: identity, policy, flow continuity, service discovery, and transport agility in one protocol story.
Clean brand split
The public technology is called NovaZel Protocol. It is the name used in protocol documents, RFC-style specifications, website copy, architecture diagrams, and Zelfire marketing. The command-line entry point stays nova because it is short, fast, and developer-friendly.
NovaZel Protocol
Formal protocol brand for docs, RFCs, product pages, diagrams, standards, and customer-facing language.
nova CLI
Practical developer command used to inspect identities, resolve services, publish endpoints, trace flows, and test access.
AZ
Atlas
Atlas resolves a friendly NovaZel name into identity, current locators, relay hints, service metadata, and policy references.
FX
FUSE
FUSE creates application flows that can survive carrier changes, prioritize traffic, and separate session identity from network location.
ZF
Zelfire
Zelfire supplies the policy, risk, enforcement, and evidence layer so NovaZel sessions can be governed instead of merely routed.
Core inventions
NovaZel invented identity-first network flows.
The central invention is the NovaZel Flow: a cryptographically verified, policy-bound, transport-independent session that lets browsers, apps, services, gateways, relays, and security systems communicate through identity instead of unstable address location.
The invention statement
NovaZel Protocol introduces identity-first network flows for the zero-trust web. A NovaZel Flow binds service identity, user or device identity, Zelfire policy, route choice, traffic intent, Zelen quantum-safe protection, and session evidence into one verifiable connection object.
What is new
A flow is no longer just a socket between addresses. It is a governed trust object with identity, policy, mobility, crypto profile, and evidence attached.
What it enables
Vega can open
novazel:// services, Zelfire can decide access before a session opens, and NovaZel can move the flow across carriers without losing trust context.
01
NovaZel Flow
A durable application session bound to verified identities, policy decision, traffic class, crypto profile, and evidence chain — not merely to an IP address or port.
02
Atlas Trust Record
A signed resolver record that maps a service name to NZID, public key, locators, relay preferences, service intent, policy requirements, and Zelen protection profile.
03
Policy-bound handshake
The connection does not simply open and then ask the app to protect it. NovaZel verifies identity and Zelfire policy before the flow becomes active.
04
Zelen-sealed evidence
Flow facts, policy outcomes, and sensitive objects can be sealed as quantum-safe Zelen containers so evidence remains protected beyond the lifetime of the session.
05
Vega browser binding
A browser tab can become a verified identity flow. Vega opens novazel:// resources with service verification, policy explanation, and flow tracing.
06
Relay without reading
Relay nodes can assist delivery when direct paths fail while payload privacy remains between verified endpoints and Zelen-protected objects remain sealed.
NovaZel Flow object
NovaZel Flow flow_id: nzf:9A71-F2C0-8D44 client: nzid:vega-user-device service: nzid:secure-webserver name: novazel://secure.lab.zel/dashboard policy: zelfire://policies/vega-secure-browse crypto: zelen://profiles/ZELEN-PQ5 traffic_class: STREAM carrier: QUIC direct, relay fallback evidence: Zelen-sealed session timeline
The problem
TCP/IP moves packets well. Modern security needs to move trust.
Classic networking was designed around reachability. Today’s environments need identity, browser control, policy enforcement, private services, cloud movement, device mobility, and evidence. Those concerns are usually bolted on separately.
🚨 TCP/IP Is Broken — Read the article →01
Addresses are not identities
An IP address says where something appears to be. It does not prove which service, user, browser, or gateway is actually behind the connection.
02
Private services are hard to expose safely
Teams often open inbound ports, place services behind complex VPNs, or stitch together proxies just to reach one internal webserver.
03
Policy is scattered
Firewall rules, browser rules, cloud rules, identity rules, and endpoint rules can drift apart. NovaZel is designed to let one Zelfire policy intent travel with the session.
04
Sessions break when paths change
Users move from office Wi-Fi to mobile networks. Services move across regions. Address-bound sessions are fragile unless another layer fixes them.
05
Browsers need higher-trust navigation
A browser can show a URL, but security teams also want verified service identity, policy decision context, route awareness, and audit-ready session evidence.
06
Relays should not become readers
Fallback infrastructure should help packets move when direct paths fail, but it should not become a place where private session data is exposed.
Improvement over classic TCP/IP usage
NovaZel does not fight the internet. It gives the internet a smarter application layer.
The existing internet remains the underlay. NovaZel adds identity, naming, flow control, policy, routing intent, and private service access above it.
| Concern | Classic address-first model | NovaZel Protocol model |
|---|---|---|
| Who am I connecting to? | Usually inferred from DNS, certificates, routing, and application configuration. | Resolved to a NovaZel Identity. The peer must prove possession of the matching private identity key. |
| Where is the service? | A host address or load balancer endpoint is the primary target. | A service name resolves to identity plus current locators, relay hints, and service metadata. |
| What policy applies? | Policy is spread across browser, firewall, identity, endpoint, and cloud systems. | Zelfire policy can be evaluated before and during the flow, then recorded as part of the session story. |
| What if the path changes? | Sessions can break or reconnect at the application layer. | The FUSE flow is tied to identity and flow ID, while the carrier path can adapt underneath. |
| Can a private webserver stay private? | Often needs public exposure, VPN access, or a specialized reverse proxy. | The service can publish a NovaZel identity through a gateway while keeping raw inbound access closed. |
| Do relays see content? | Depends on the proxy/VPN design. | Relays are designed to forward encrypted capsules and metadata needed for delivery, not read private payloads. |
Smart overlay reality
NovaZel does not rip out TCP/IP. It makes TCP/IP survivable for zero-trust applications.
Routers, ISPs, BGP, fiber, Wi-Fi, 5G, cloud backbones, NAT, and UDP still move the physical packets. NovaZel runs above that underlay as an encrypted, identity-first overlay. The underlay answers where can packets physically go? NovaZel answers who is this, is the flow allowed, what path should carry it, what evidence proves it, and how should it recover when the underlay fails?
UDP
QUIC is the fast carrier
NovaZel prefers QUIC over UDP because it gives encrypted, multiplexed, low-latency transport behavior. But QUIC is still only a carrier. NovaZel adds identity, policy, flow state, evidence, Zelen-sealed objects, and carrier selection above it.
ID
Identity is above the address
IP addresses, ports, NAT mappings, DNS answers, and relay locators are treated as temporary reachability hints. A service or client is trusted only after proving control of its NZID and matching the signed Atlas trust record.
FIX
FUSE routes around underlay failure
When the old internet misroutes, congests, blocks, or breaks a path, FUSE can migrate, stripe, pause, resume, relay, or deny capsules while preserving the same identity-bound flow and policy state.
Underlay vs NovaZel overlay
Physical internet underlay fiber, radio, Wi-Fi, 5G, Ethernet, cloud network ↓ Legacy packet routing IP, UDP, TCP, NAT, BGP, ISP paths ↓ QUIC carrier encrypted UDP transport, streams, datagrams, migration ↓ NovaZel overlay NZID identity proof Atlas trust record Zelfire policy decision FUSE flow ID and sequence state Zelen-sealed evidence and object protection MP-FUSE carrier scheduler eBPF-native fast-path enforcement where available
What the app sees
Application asks: open novazel://secure-ai-workspace NovaZel handles: resolve service identity verify service NZID authorize user/device/agent policy select carrier lanes create FUSE flow seal evidence with Zelen recover if TCP/IP path fails Application receives: one stable verified flow no raw subnet exposure no address-based trust assumption
TCP/IP rescue features
When the legacy internet makes mistakes, NovaZel catches them at the flow layer.
NovaZel accepts the real world: BGP can be hijacked, NATs can block peers, ports can exhaust, routers can congest, Wi-Fi can collapse, and DNS answers can be poisoned. NovaZel does not pretend those problems disappear. It detects them, limits blast radius, and routes around them using identity-bound FUSE flows.
BGP
BGP hijack correction
If the underlay sends packets to the wrong location, the impostor still cannot prove the service NZID or decrypt Zelen-protected artifacts. FUSE marks the path compromised or dead, then moves the flow to another Atlas locator or relay.
MUX
One-port payload multiplexing
The operating system can expose one UDP carrier port while NovaZel multiplexes millions of logical FUSE streams inside capsules using flow IDs, stream IDs, traffic classes, and policy state.
NAT
Native NAT traversal
Atlas and relays act as signaling infrastructure. Peers verify NZIDs, exchange reachable locators, attempt UDP hole punching, and fall back to relay without forcing every developer to build STUN/TURN-style machinery.
SEM
Semantic congestion control
When bandwidth collapses, FUSE decides what survives. CRITICAL and CONTROL capsules can continue while BULK traffic pauses, STREAM adapts, and agent/tool flows are rate-limited by purpose.
| Legacy failure | What TCP/IP sees | What NovaZel does | Result |
|---|---|---|---|
| BGP hijack | Packets follow the wrong underlay route. | Handshake identity fails, path is scored down, flow migrates to fallback locator or relay. | The attacker may receive packets but cannot become the service. |
| Port exhaustion | Host has finite TCP/UDP port namespace and connection tables. | One carrier can hold many FUSE flows, streams, tools, browser tabs, and services. | Logical scale moves inside the overlay instead of burning OS ports. |
| NAT/firewall block | Incoming path may be unreachable. | Outbound rendezvous, hole punching, and relay fallback are handled by Atlas/NovaZel nodes. | Developers request a service identity, not a public IP trick. |
| Random packet loss | Bad Wi-Fi or congestion drops packets blindly. | Traffic classes and policy let FUSE prioritize what matters and pause what does not. | Critical flows survive the slowdown; bulk traffic yields. |
| Captive portal or MITM | The network can redirect traffic. | Service identity proof fails if the endpoint cannot prove the expected NZID. | Local network control is not treated as service authority. |
| Cloud egress choke point | Traffic often routes through expensive centralized NAT or egress paths. | Cost-aware carrier policy can prefer direct peering or lower-cost approved relays for BULK traffic. | Security policy can include cost as a first-class routing dimension. |
Architecture
The NovaZel stack: browser, policy, identity, flows, capsules, and carriers.
NovaZel keeps the current internet as the transport foundation, then overlays a service-aware and policy-aware protocol plane that can be used by Vega Browser, Zelfire, gateways, and developer tools.
ApplicationsWho uses it
Rocheston Vega Browser
Private web apps
Zelfire console
Operator tools
Service APIs
Access LayerHow apps enter
novazel:// URI handler
NovaZel Gateway
Local node
nova CLI
Control PlaneTrust and policy
Atlas resolver
Zelfire policy
Risk score
Session evidence
Protocol PlaneNovaZel core
NZID identity
FUSE flow engine
Capsules
Traffic classes
Path scoring
CarriersHow bytes move
Direct encrypted carrier
TLS fallback
Relay forwarding
Future mesh paths
UnderlayWhat already exists
TCP/IP internet
Wi-Fi
5G
Cloud networks
Enterprise networks
Identity plane
NovaZel names the actor first. A user, browser, gateway, service, and relay all have identities that can be verified independently from their temporary network address.
Policy plane
Zelfire policy decides whether the flow should open, which path class it may use, whether a relay is allowed, and what evidence should be retained.
Flow plane
FUSE turns a request into a durable flow with sequence, stream, and traffic-class semantics so the application experience can stay stable even when the carrier changes.
Technical section
How NovaZel works under the hood.
The protocol is easiest to understand as five separate objects: identity, locator, flow, carrier, and crypto/evidence envelope. NovaZel keeps them separate so trust is not confused with reachability.
1. Identity
A NovaZel Identity, or NZID, is the stable name of a participant. It is used to verify who is speaking, even if the peer connects through a different address, relay, network, or cloud region.
2. Locator
A locator is a current way to reach an identity. A service can have multiple locators: direct endpoint, fallback endpoint, relay route, region-specific route, or gateway route.
3. Flow
A flow is the application session. FUSE tracks flow ID, peer identity, traffic class, sequencing, acknowledgments, and migration state.
4. Carrier
A carrier is the underlying path used to move capsules. NovaZel can prefer a direct encrypted carrier, fall back to a TLS path, or forward through a relay.
5. Zelen envelope
Zelen Quantum Encryption protects sensitive NovaZel objects such as exported evidence, private service descriptors, policy bundles, and long-lived session records.
Connection lifecycle
Resolve
The client resolves novazel://service through Atlas and receives the service NZID, public key, locator list, relay hints, and policy references.
Evaluate policy
Zelfire checks user, browser, device, location, data sensitivity, risk, and requested service action before the session opens.
Handshake
The peers exchange HELLO and WELCOME capsules, prove identity, select a protocol version, and establish trust for the flow.
Select Zelen protection
If the service requires quantum-safe protection, NovaZel binds the flow to a Zelen profile such as ZELEN-PQ5 for object encryption, signature binding, and evidence sealing.
Open flow
FUSE creates a flow ID and selects a traffic class such as CONTROL, STREAM, SYNC, BULK, FLASH, or CRITICAL.
Move capsules
Application data is wrapped into NovaZel capsules and sent over the best available carrier. Relays can help deliver without becoming application readers.
Record evidence
Zelfire receives session facts: who connected, what service identity was reached, what policy allowed it, and how the flow behaved.
Conceptual Atlas record
{
"name": "secure.lab.zel",
"scheme": "novazel://",
"service_nzid": "nzid:NZ6Q7...",
"locators": [
{ "type": "direct", "endpoint": "edge-a", "priority": 1 },
{ "type": "relay", "endpoint": "relay-us-east", "priority": 2 }
],
"zelfire_policy": "zelfire://policies/vega-secure-browse",
"crypto_profile": "zelen://profiles/ZELEN-PQ5",
"service_class": "private-web",
"expires": "short-lived",
"signature": "signed-by-service-identity"
}
Capsule family
HELLO prove client identity WELCOME prove service identity OPEN_FLOW create FUSE flow DATA reliable application payload DATAGRAM low-latency payload ACK delivery confirmation PATH_PROBE measure carrier quality PATH_SCORE report route metrics POLICY_HINT carry Zelfire policy context ZELEN_SEAL bind evidence or objects to Zelen protection RELAY_FORWARD forward encrypted capsule CLOSE end the flow
Traffic classes
- CONTROL: protocol and policy control messages.
- FLASH: low-latency events that are useless if late.
- STREAM: browser sessions, video, and interactive traffic.
- SYNC: normal reliable messages and API calls.
- BULK: large transfers and background work.
- CRITICAL: high-priority security or safety actions.
Policy envelope
Zelfire can attach a policy envelope to the flow: user role, device trust, browser posture, service sensitivity, allowed actions, data handling rules, and evidence requirements.
Relay privacy
A relay path is designed to know enough to forward the capsule, but not enough to read the application payload. Delivery and privacy stay separate.
Zelen crypto profile
NovaZel can require a service to use Zelen Quantum Encryption for protected objects, evidence exports, and sensitive policy material while the live flow moves over direct or relay carriers.
Advanced technical hardening
NovaZel uses QUIC as the fast carrier, then adds identity, policy, Zelen, ratcheting, revocation, and evidence above it.
QUIC is excellent at moving encrypted streams across modern networks. NovaZel uses that strength, but does not stop there. NovaZel adds verified NZIDs, signed Atlas records, FUSE flow state, Zelfire authorization, relay controls, metadata-minimizing policy proofs, Zelen Quantum Encryption for durable objects, and continuous trust evaluation. The result is not just a faster pipe — it is a cryptographically identified, policy-bound, evidenced flow.
QUIC is transport. NovaZel is trust.
A normal QUIC session can protect bytes in flight. NovaZel turns the session into a named security object: who the client is, who the service is, what policy allowed the connection, what tool or browser tab opened it, what carrier moved it, what evidence was produced, and what Zelen protection was required.
Carrier layer
QUIC where available, TCP/TLS fallback where required, relay when direct reachability fails, and the existing TCP/IP internet underneath.
NovaZel layer
NZID proof, Atlas trust records, FUSE continuity, Zelfire decisions, Zelen-protected artifacts, flow evidence, and continuous security state.
NovaZel layered security model
Application / Vega Browser / AI Agent ↓ NovaZel Flow NZID client identity proof NZID service identity proof Atlas signed service record Zelfire zero-trust policy decision FUSE flow ID, nonces, sequences, ACK state traffic intent: CONTROL / FLASH / STREAM / SYNC / BULK / CRITICAL eBPF fast-path policy drop for invalid capsules MP-FUSE path lanes and replay windows Proof-of-Transit evidence chain Zelen profile: ZELEN-PQ5 or policy-selected profile telemetry mode: FHE / ZK-minimized / sealed export evidence mode: Zelen-sealed ↓ Carrier QUIC direct preferred parallel QUIC lanes for MP-FUSE TCP/TLS fallback privacy relay when direct reachability fails ↓ Existing TCP/IP underlay
HP
Hybrid post-quantum cryptography
NovaZel can require a hybrid Zelen profile that combines classical key agreement, such as X25519, with post-quantum key encapsulation, such as ML-KEM. The combined secret is fed into the flow key schedule so the protocol does not bet everything on one cryptographic family.
HW
Hardware-rooted NZIDs
High-value user, service, server, and agent NZID keys can be generated or protected inside TPMs, YubiKeys, Secure Enclaves, HSMs, or cloud TEEs, reducing the risk that a stolen software key becomes a permanent identity compromise.
RV
Cryptographic revocation trees
Revocation can be published as Sparse Merkle Trees or similar accumulators, allowing gateways, browsers, and services to verify whether an NZID is still trusted without depending on a single live database lookup.
DD
State-exhaustion resistance
Atlas, gateways, and relays can require stateless client puzzles and FUSE SYN-cookie style tokens before allocating flow memory or asking Zelfire for expensive policy evaluation.
ZK
Zero-knowledge policy proofs
When policy allows it, a client can prove it satisfies posture requirements without exposing raw device details. Zelfire learns that the rule passed, not necessarily every private attribute behind the rule.
BT
Blind relay authorization
Relay access can require signed relay tokens while preserving privacy. Zelfire can authorize relay usage, and the relay can verify the token, without learning unnecessary user identity details.
AI
Ephemeral task-bound agent NZIDs
Agent identities can be short-lived and bound to one approved task, prompt, tool set, budget, and deadline. When the task ends, the identity is revoked, expired, or destroyed.
DL
Semantic DLP in FUSE
NovaZel can apply semantic DLP before capsules leave the node: checking purpose, destination identity, action type, data class, and risky intent, not just static keywords.
CT
Continuous trust verification
A flow is not trusted forever because it passed once. NovaZel can degrade trust, step up authentication, reduce permissions, reroute, quarantine, or terminate a flow when behavior changes.
| Hardening area | Technical mechanism | Security result |
|---|---|---|
| Live transport | QUIC direct path with path validation, stream multiplexing, and encrypted transport. | Fast carrier behavior without treating the IP address as identity. |
| Transport fallback | TCP/TLS fallback only when QUIC is unavailable; policy records the downgrade. | Reachability without silent security weakening. |
| Identity proof | NZID derives from public key; peer must prove private-key possession inside the handshake. | Service/client identity is cryptographic, not just address-based. |
| Quantum-safe object protection | Zelen Quantum Encryption protects evidence, policy bundles, service descriptors, agent memory exports, and signed reports. | Long-lived objects can be protected against harvest-now-decrypt-later risk. |
| Hybrid crypto | Hybrid mode combines classical and post-quantum secrets into the flow key schedule. | Resilience if either a classical or post-quantum component is later weakened. |
| Key storage | Hardware-backed NZID keys for critical services, administrators, browser identities, and agent runtimes. | A stolen process memory dump is less likely to become a reusable identity theft event. |
| Revocation | Signed revocation roots and Sparse Merkle proofs for NZID status. | Fast, verifiable revocation without a single online trust bottleneck. |
| DDoS pressure | Client puzzles, FUSE SYN-cookies, stateless tokens, token buckets, retry budgets, and early malformed-capsule drop. | Attackers pay CPU or fail early before expensive state and policy checks are allocated. |
| Metadata privacy | Zero-knowledge posture proofs, blinded relay tokens, minimized logs, split telemetry, and Zelen-sealed evidence. | Security can be enforced without turning every session into an unnecessary metadata honeypot. |
| Relay abuse | Relay authorization tokens, destination allowlists, rate limits, purpose binding, and anomaly scoring. | Relays can help privacy and reachability without becoming free botnet tunnels. |
| Kernel-speed enforcement | eBPF-native FUSE fast path validates flow IDs, replay windows, capsule type, traffic class, and policy token before user-space delivery. | Invalid or out-of-policy capsules are dropped close to the packet path instead of waking application services. |
| Data sovereignty | Cryptographic Proof of Transit binds approved relay/gateway signatures, region attestations, and path checkpoints into FUSE evidence. | Regulated flows can prove they stayed inside approved infrastructure domains. |
| Carrier failure | MP-FUSE stripes one identity flow across multiple live carriers and reorders capsules at the FUSE layer. | Wi-Fi, 5G, wired, and satellite can be active at the same time instead of acting as cold failover. |
| Telemetry breach risk | FHE-encrypted telemetry allows selected aggregate risk scoring over encrypted counters and flow metrics, with Zelen-sealed export for reports. | Zelfire can reason over behavior while minimizing exposed operational metadata. |
| Agentic AI containment | Ephemeral task NZIDs, tool-bound flows, semantic DLP, quotas, step-up challenges, and human approval gates. | Agents can act, but only through the flows their policy explicitly permits. |
| Evidence integrity | Zelen-sealed evidence chain linking resolution, policy, handshake, path changes, relay use, and close events. | Investigators can reconstruct what happened without trusting mutable application logs alone. |
NovaZel Apex specification
Apex turns the smart overlay into kernel-speed, sovereign, multi-path, encrypted-analytics infrastructure.
NovaZel already defines identity-first, policy-bound overlay flows. The Apex specification adds four industry-defining tracks: eBPF-native FUSE for kernel-speed enforcement, Cryptographic Proof of Transit for data sovereignty, MP-FUSE for active multipath continuity, and FHE-encrypted telemetry for blind Zelfire analytics.
BPF
eBPF-native FUSE engine
NovaZel can compile the FUSE fast path into eBPF programs so capsule pre-validation, replay-window checks, traffic-class gates, flow-table lookups, and deny decisions happen before application services are awakened.
PoT
Cryptographic Proof of Transit
Authorized gateways and relays can add hardware-backed transit attestations to the FUSE evidence chain, proving a regulated flow traversed approved regions, clouds, facilities, and sovereign zones.
MP
MP-FUSE active multipathing
Instead of waiting for Wi-Fi to fail before using 5G, MP-FUSE can keep multiple carriers hot simultaneously and stripe one NovaZel Flow across direct QUIC lanes, relay lanes, cellular, wired, or satellite paths.
FHE
FHE-encrypted telemetry
NovaZel can stream selected counters, scores, and flow metrics to Zelfire as fully homomorphic encrypted telemetry, allowing anomaly scoring over ciphertext where practical and minimizing the metadata honeypot.
Important positioning
These frontier features should be written as NovaZel specification tracks: kernel data plane, sovereign evidence, multipath continuity, and privacy-preserving analytics. That makes them product-defining without pretending every deployment must enable every feature on day one.
Core claim
NovaZel turns a connection into a verifiable flow object: identity, policy, path, evidence, transport, telemetry, and agent authority all move together.
Frontier flow pipeline
novazel://secure-api.rocheston ↓ Atlas Trust Record NZID, locators, policy, region, Zelen profile ↓ Zelfire decision allow, deny, step-up, route constraint, telemetry mode ↓ FUSE flow creation flow_id, nonces, replay windows, traffic class, policy ref ↓ eBPF FUSE fast path early drop spoofed capsules verify flow token and replay window enforce traffic class and route lane count telemetry without exposing payload ↓ MP-FUSE scheduler lane A: QUIC / Wi-Fi lane B: QUIC / 5G lane C: relay / satellite ↓ Proof of Transit gateway signatures + region attestations + path checkpoints ↓ Zelen / FHE evidence plane sealed evidence, encrypted telemetry, auditable session proof
MP-FUSE lane state
flow_id: nzf_7KQ9...
client_nzid: nzid:user-vega-device
service_nzid: nzid:secure-webserver
policy: zelfire-policy:EU-SOVEREIGN-AI-OPS
zelen_profile: ZELEN-PQ5
telemetry: fhe-encrypted-counters
proof_of_transit: required
lanes:
- lane: wifi-quic
state: active
role: low-latency-control
loss: 0.2%
- lane: cellular-quic
state: active
role: continuity-and-burst
loss: 0.5%
- lane: relay-satellite
state: backup-hot
role: sovereign-fallback
proof: relay-attested
reorder_buffer: enabled
fec: adaptive
replay_window: per-lane-and-global
| Frontier capability | What it does | Why architects care | Spec hook |
|---|---|---|---|
| eBPF-native FUSE | Moves deterministic validation into the kernel-adjacent packet path: flow token, capsule type, replay window, policy bit, and lane selection. | Cuts proxy overhead, drops abuse early, and makes zero-trust enforcement feel like native networking. | NZP-0011 Kernel Data Plane |
| Cryptographic Proof of Transit | Accumulates signed transit evidence from approved gateways, relays, regions, and hardware-backed nodes. | Gives banks, healthcare, defense, and government customers audit-grade proof of data sovereignty. | NZP-0012 Sovereign Transit Evidence |
| MP-FUSE | Maintains several active carriers for one identity flow, with scheduling, duplication, FEC, replay protection, and reordering. | Makes movement across Wi-Fi, 5G, wired, and satellite invisible to applications and AI agents. | NZP-0013 Active Multipath Flows |
| FHE telemetry | Encrypts selected metrics so Zelfire can run aggregate scoring and anomaly detection over ciphertext where practical. | Security analytics can detect rogue agents while reducing exposure if telemetry storage is compromised. | NZP-0014 Blind Telemetry Analytics |
How eBPF-native FUSE protects the webserver
A normal private webserver behind NovaZel should not have to parse hostile traffic. The eBPF fast path can drop malformed capsules, spoofed NZIDs, expired policy tokens, replayed sequences, disallowed traffic classes, and invalid route lanes before the request reaches the Vega-facing gateway or internal HTTP service.
- Early deny for spoofed service NZID.
- Early deny for capsule sequence outside the replay window.
- Early deny for missing Zelfire policy reference.
- Early deny for agent attempting a forbidden tool/service flow.
- Per-flow counters exported as sealed or FHE-protected telemetry.
How Proof of Transit proves sovereignty
A NovaZel Flow can carry an evidence requirement such as “EU-only,” “FedRAMP boundary,” or “Rocheston sovereign lab.” Each approved transit node contributes a signed checkpoint. The final evidence bundle can be Zelen-sealed and exported to auditors without exposing payload contents.
- Region policy embedded in the Atlas Trust Record.
- Gateway attestation bound to hardware identity.
- Transit checkpoints chained into FUSE sequence state.
- Unexpected region or relay breaks the proof and triggers policy action.
- Zelen-sealed evidence report for compliance review.
Pragmatic OMG features
NovaZel survives outages, key exposure, and cloud cost traps.
The next specification layer turns NovaZel from a strong overlay into a resilient operating fabric: it can keep local trust running without the internet, rotate capsule keys continuously, and choose paths based on business cost as well as latency and security.
DARK
NovaZel Dark: Atlas-Free Local Mesh
If the WAN, DNS, or global identity provider is unreachable, local NovaZel Nodes can discover each other on a trusted local mesh. NZIDs remain verifiable because they are cryptographic, and policy bundles can be exchanged as Zelen-sealed artifacts.
RAT
Per-capsule FUSE key ratcheting
FUSE can rotate key material forward for every DATA capsule or capsule window. A stolen flow key becomes a narrow, expiring window instead of a permanent session compromise.
$
Economic routing
Zelfire policy can score carrier lanes not only by latency, loss, trust, and sovereignty, but also by cloud egress cost, NAT Gateway cost, peering cost, and relay budget.
NovaZel Dark local flow
WAN status: offline Atlas global: unreachable Local discovery: enabled Factory sensor discovers: nzid:factory-controller-07 Controller sends: Zelen-sealed policy bundle signed local trust root revocation proof snapshot posture proof request FUSE opens: local mesh flow zero-trust policy still enforced no public internet required
FUSE key ratchet state
flow_id: nzf_9M2K... ratchet_epoch: 5001 prev_epoch: erased next_key = KDF(current_key, capsule_hash, transcript_hash) Compromise at capsule 5000: cannot decrypt capsules 1..4999 cannot predict capsule 5001+ triggers trust degradation if memory theft evidence appears
| Feature | Problem solved | NovaZel mechanism | Business value |
|---|---|---|---|
| NovaZel Dark | Cloud identity and DNS fail during WAN outage. | Local discovery, cached signed Atlas records, Zelen-sealed policy bundles, local revocation proofs. | Ships, factories, defense sites, hospitals, and field teams keep operating safely. |
| Key ratcheting | A stolen session key can expose too much traffic. | Per-capsule or per-window key evolution with transcript binding and old-key erasure. | Compromise window shrinks dramatically; flows self-heal after exposure. |
| Economic routing | Cloud egress and NAT gateway charges turn network design into a bill shock. | Path scheduler includes cost hints, peering policy, bulk/offload lanes, relay budget, and traffic class. | BULK and backup flows can prefer low-cost approved paths without weakening trust. |
Ultimate assurance track
Silicon-bound identity, time-independent trust, and mathematically safer packet parsing.
The final NovaZel assurance track targets the most serious critiques: virtualized identity cloning, clock rollback attacks, and parser memory exploits. These features are written as optional high-assurance profiles for critical infrastructure, defense, regulated AI, and sovereign cloud deployments.
PUF
Silicon-bound NZIDs via PUF
For high-assurance hardware, an NZID can be tied to a Physical Unclonable Function or hardware root so the service identity is derived from silicon properties, secure enclave keys, or hardware attestation rather than a cloneable disk image.
TIME
Cryptographic Time Consensus
FUSE does not blindly trust the host clock. It can combine sequence progression, signed Atlas time checkpoints, policy epochs, nonces, round-trip windows, and revocation roots to reject replayed or expired state even under NTP spoofing.
FV
Formally verified capsule parsing
The FUSE capsule parser is specified for memory-safe implementation and formal verification, with strict length checks, version gates, constant-time decisions where required, fuzzing, and proof targets for malformed input handling.
| Assurance target | Critic concern | NovaZel answer | Deployment profile |
|---|---|---|---|
| PUF / hardware NZID | A VM snapshot or vTPM clone could copy identity. | Bind high-value NZIDs to hardware roots, silicon challenge-response, HSMs, TEEs, or secure enclaves; require attestation before policy allows flow creation. | Critical services, gateways, agents, sovereign relays. |
| Time consensus | NTP rollback could revive expired tokens or policy bundles. | Use relative flow time, sequence state, signed policy epochs, Atlas checkpoints, and revocation-tree roots instead of trusting the local wall clock alone. | Banking, defense, audit-heavy systems. |
| Formal parser assurance | Malformed packets exploit memory bugs in parsers. | Define the wire format precisely; implement parsing in memory-safe code; add fuzzing, property tests, proof artifacts, and fail-closed validation. | All deployments, mandatory for core parser. |
How to say it publicly
NovaZel is not merely encrypted. It is identity-bound, policy-proven, route-aware, sovereign, ratcheted, and designed for verifiable parser safety.
How to say it technically
The high-assurance profile combines hardware-rooted NZIDs, cryptographic time consensus, strict capsule grammar, memory-safe parsers, formal properties, continuous revocation proofs, and Zelen-sealed evidence.
Example flow
Rocheston Vega Browser opens a NovaZel webserver.
This example shows how a private web app can be made reachable to authorized Vega users without becoming a raw public website.
The scenario
An internal security dashboard runs as a normal webserver on a private machine. The service is published through NovaZel Gateway as novazel://secure.lab.zel. A user opens that address in Rocheston Vega Browser. Zelfire policy decides whether the browser, user, device, and requested service are allowed.
Without NovaZel
Expose the webserver, place it behind a VPN, manage firewall rules, and hope the browser and network policy agree.
With NovaZel
Publish service identity, keep the server private, verify the peer, enforce Zelfire policy, and route through direct or relay paths.
NovaZel webserver concept
# The webserver remains a normal internal app. http://127.0.0.1:8080 # NovaZel Gateway publishes it as an identity-verified service. nova service publish secure-dashboard \ --name novazel://secure.lab.zel \ --target http://127.0.0.1:8080 \ --policy zelfire://policies/vega-secure-browse # Vega opens this address like a first-class secure resource. novazel://secure.lab.zel/dashboard
Vega recognizes the NovaZel scheme
The browser sees novazel:// and sends the request to the NovaZel local engine instead of treating it like a normal public web address.
Atlas resolves service identity
Atlas returns the service NZID, service public key, current locator set, relay options, and a Zelfire policy reference.
Zelfire makes the access decision
Zelfire checks identity, user role, device posture, browser posture, risk, geo, time, and service sensitivity. The decision becomes part of the session evidence.
FUSE opens a browser flow
Vega’s NovaZel engine opens a FUSE flow to the webserver identity. The webserver sees a verified NovaZel client, not a random source address.
Gateway bridges to the private webserver
On the service side, NovaZel Gateway translates the verified NovaZel flow into local HTTP traffic for the private webserver.
Vega renders the response
The user sees the dashboard normally, while NovaZel maintains identity, policy context, path state, and evidence in the background.
Zelfire integration
NovaZel is the protocol fabric. Zelfire is the policy brain.
NovaZel gives Zelfire a way to express policy at the exact moment a browser, user, service, gateway, or automation connects. Zelen then gives Zelfire a quantum-safe way to seal the durable evidence, service descriptors, and policy artifacts produced by those flows.
P
One policy story
Define who may connect to what, through which client, from what device posture, under which risk state, and with what evidence requirements.
E
Evidence-aware sessions
Each permitted flow can emit a clean story: requesting identity, browser identity, service identity, policy result, route class, and session timing.
A
Automated action
If risk changes, Zelfire can ask NovaZel to close a flow, move it to a safer path, require re-verification, or deny the next request.
Zelen quantum encryption
NovaZel uses Zelen for quantum-safe object protection.
NovaZel is the identity-first flow protocol. Zelen Quantum Encryption is the Rocheston quantum-safe object encryption layer used to protect sensitive NovaZel artifacts: exported evidence, policy bundles, service descriptors, sealed session records, and private objects that must remain safe after the flow ends.
How Zelen fits NovaZel
A live NovaZel Flow moves application traffic through verified identities, policy, capsules, carriers, and relays. Zelen protects the durable objects around that flow — the things attackers might store, harvest, replay, or analyze later. In simple terms: NovaZel moves trust; Zelen seals trust.
Flow plane
FUSE, capsules, paths, relays, Vega browser access, and service routing.
Crypto object plane
Zelen-protected objects, Zelen profiles, quantum-safe key encapsulation, signatures, and sealed evidence.
Zelen binding example
novazel://secure.lab.zel/dashboard service_nzid: nzid:NZ6Q7... zelfire_policy: zelfire://policies/vega-secure-browse crypto_profile: zelen://profiles/ZELEN-PQ5 evidence_mode: zelen-sealed Zelen protected objects: session.evidence.zelen policy.bundle.zelen service-descriptor.zelen exported-flow-report.zelen
K
ML-KEM key encapsulation
Zelen profiles can use ML-KEM for quantum-safe key establishment, including a high-security ZELEN-PQ5 profile for sensitive NovaZel evidence and service objects.
S
ML-DSA signatures
Zelen can bind encrypted objects to post-quantum digital signatures so sealed NovaZel evidence can prove who created or approved it.
A
AES-256-GCM payload encryption
Object payloads can be encrypted with authenticated encryption, binding ciphertext to headers and rejecting tampered objects before plaintext release.
Z
.zelen containers
NovaZel evidence and policy material can be exported as self-describing .zelen containers with suite-agile, forward-compatible metadata.
L
Zero-secret logging
Security events can describe key generation, encryption, decryption, policy, and flow activity without logging keys, passphrases, or plaintext.
F
Fail-closed validation
NovaZel can require protected objects to authenticate successfully before evidence, service descriptors, or private content are released.
Important wording
Public copy can say “NovaZel uses Zelen Quantum Encryption”. Technical copy should also explain that Zelen is a quantum-safe / post-quantum object encryption layer, not a claim that NovaZel replaces the entire internet with quantum hardware. NovaZel governs identity-first flows; Zelen protects the durable objects and evidence around those flows.
Security deep dive
QUIC is the fast carrier. NovaZel adds identity, policy, Zelen, and evidence above it.
NovaZel does not claim that raw transport speed alone is security. It uses QUIC as a modern, encrypted, multiplexed carrier where available, then layers NovaZel identity, signed Atlas records, FUSE flow continuity, Zelfire policy, relay privacy, and Zelen Quantum Encryption for long-lived objects and evidence. In short: QUIC moves the packets; NovaZel moves verified trust.
How NovaZel uses QUIC, but goes beyond QUIC
QUIC gives NovaZel a strong live carrier: encrypted sessions, streams, datagrams, lower-latency setup, and path migration behavior. NovaZel then adds the missing application-trust layer: who the service is, who the client is, which policy allowed the flow, which tool or browser tab opened it, whether a relay was used, and what evidence should be sealed.
QUIC carrier layer
Secure transport, streams, datagrams, path validation, congestion behavior, and modern UDP reachability.
NovaZel trust layer
NZID proof, Atlas trust records, FUSE flow IDs, Zelfire policy decisions, Zelen-sealed evidence, and service-level authorization.
NovaZel protected flow stack
NovaZel protected flow user / browser / agent identity service NZID identity proof Atlas signed trust record Zelfire policy decision FUSE flow ID + sequence state NovaZel capsule metadata Zelen-sealed evidence + objects QUIC carrier when available TCP/TLS fallback when required Relay path when direct reachability fails Existing TCP/IP internet underlay
Q
QUIC as the fast lane
NovaZel can ride QUIC for encrypted, multiplexed, low-latency carrier behavior while avoiding the mistake of treating a network address as identity.
I
Identity above transport
The peer must prove ownership of its NZID. A working IP address, DNS answer, relay path, or TLS tunnel alone is not enough.
P
Policy before payload
Zelfire can decide whether the flow is allowed before application payloads move, then re-evaluate if posture, risk, route, user, or tool context changes.
Z
Zelen quantum encryption
Zelen protects the durable objects around the flow: policy bundles, service descriptors, agent memory exports, session evidence, and forensic reports.
| Threat or failure mode | NovaZel protection | Where it is enforced |
|---|---|---|
| Service spoofing | Service identity must resolve to a signed Atlas record and prove ownership of the NZID private key. | Atlas + handshake |
| Client impersonation | The client signs handshake material and binds its identity to the flow ID, policy decision, and session nonces. | NOVA/NZID handshake |
| DNS-style poisoning | A name is not trusted merely because it resolves. The service NZID, public key, expiration, sequence, and signature must validate. | Atlas resolver |
| Atlas record tampering | Records are signed; stale sequence numbers and expired records are rejected; service key mismatch fails closed. | Atlas trust record |
| Man-in-the-middle attacks | Transport encryption protects the carrier, while NovaZel identity proof verifies the actual service and client above transport. | QUIC/TLS + NZID proof |
| Replay attacks | Nonces, timestamps, flow IDs, sequence numbers, ACK windows, and policy decision IDs make old capsules invalid or detectable. | FUSE + capsules |
| Session hijacking | Stealing an address or path is insufficient; the attacker must prove the cryptographic NZID and stay inside the valid flow state. | FUSE + identity proof |
| Connection migration abuse | Carrier path changes are validated and bound to the same identity-first flow, not blindly trusted because a packet arrived. | QUIC path validation + FUSE |
| IP spoofing | Network source addresses are treated as locators, not trust anchors. Identity proof and path validation are required. | Transport + identity plane |
| Protocol downgrade | The selected NovaZel version, crypto profile, carrier type, and policy mode are included in flow evidence and can be pinned by policy. | Handshake + Zelfire |
| Crypto downgrade | Services can require specific Zelen profiles, reject weaker profiles, and fail closed when required protection is unavailable. | Zelen binding + policy |
| Relay snooping | Relays forward encrypted capsules and should only see routing metadata required to deliver the flow. | Relay + capsule encryption |
| Relay impersonation | Relay hints are published through signed Atlas records; relay services can also carry NZIDs and trust policy. | Atlas + relay policy |
| Relay tampering | Capsule authentication and endpoint verification detect unauthorized changes before plaintext is accepted. | Capsule integrity |
| Route manipulation | Path probes, path scores, policy constraints, and evidence timelines expose suspicious route changes or forced relay behavior. | Routing + evidence |
| Public webserver exposure | NovaZel Gateway can keep raw services private while exposing only a verified service identity through novazel://. | Gateway + Atlas |
| Lateral movement | Access is service-scoped, not network-wide. A permitted flow to one service does not imply reachability to an entire subnet. | Zelfire policy + gateway |
| Over-privileged access | Policies can bind access to user role, device posture, browser type, action, service sensitivity, and requested data class. | Zelfire policy envelope |
| Credential stuffing | NovaZel does not rely on password possession alone; flows require identity, policy, posture, and service verification. | Identity + policy |
| Bearer token replay | Tokens can be scoped to a flow, traffic class, service NZID, policy decision, short lifetime, and Zelen-sealed artifact. | Policy + Zelen |
| Phishing via lookalike service | Vega can display the verified service identity and policy explanation instead of trusting a visual URL alone. | Vega + Atlas |
| Browser tab confusion | Each novazel:// tab can be bound to a specific flow, service NZID, user context, and policy result. | Vega browser binding |
| Cross-tenant confusion | Tenant, service, region, and policy identifiers can be embedded in signed records and flow evidence. | Atlas + policy |
| API abuse | Per-flow budgets, quotas, rate limits, action labels, and traffic classes can be enforced before requests reach the service. | FUSE + Zelfire |
| Data exfiltration | Outbound destinations can be restricted to approved service identities, with evidence and DLP policy attached to flows. | Gateway + Zelfire |
| Command-and-control egress | Unknown raw destinations can be blocked while approved NovaZel service identities remain reachable. | Policy + egress control |
| Packet tampering | Authenticated transport, capsule validation, signatures, and object authentication reject unauthorized mutation. | QUIC/TLS + capsules + Zelen |
| Long-term harvest-now-decrypt-later risk | Sensitive durable objects can be sealed with Zelen quantum-safe profiles so stored evidence and descriptors resist future decryption risk. | Zelen Quantum Encryption |
| Evidence tampering | Session timelines, policy decisions, route changes, and reports can be Zelen-sealed and chained for audit. | Zelen + Zelfire evidence |
| Forensics gaps | NovaZel can produce a structured timeline: resolve, verify, authorize, open, move, relay, deny, close, and export. | Evidence plane |
| Posture change during session | Zelfire can request re-verification, path change, reduced capability, or flow termination when risk changes. | Continuous policy |
| Insider misuse | Even allowed access can be evidenced by identity, policy, action class, time, service, and route. | Evidence + audit |
| Untrusted plugins or tools | Tools can be given their own service identities and allowed only through explicitly approved NovaZel flows. | Agent/tool policy |
| Unsafe automation | Automated clients can be restricted by action class, traffic class, service NZID, human approval, and evidence requirements. | Agentic AI controls |
| BGP hijacking | The underlay may misroute packets, but the attacker cannot prove the target service NZID. FUSE fails the path, records evidence, and migrates to another locator or relay. | Atlas + FUSE + relay |
| Port exhaustion | One UDP/QUIC carrier can multiplex many logical FUSE flows and streams using cryptographic flow IDs instead of consuming public ports for every application session. | Gateway + FUSE multiplexing |
| NAT traversal failure | Atlas signaling, outbound rendezvous, hole punching, and relay fallback help peers connect without exposing raw inbound services. | Atlas + relay network |
| Congestion collapse | Semantic congestion control pauses BULK, preserves CRITICAL/CONTROL, and adapts STREAM while maintaining policy evidence. | FUSE scheduler |
| WAN outage | NovaZel Dark can use Atlas-Free Local Mesh with cached signed records, local discovery, and Zelen-sealed policy bundles. | Local mesh + Zelen policy |
| Session-key memory theft | Per-capsule or per-window FUSE key ratcheting limits forward and backward decryption exposure after a key compromise. | FUSE ratchet |
| Cloud egress cost abuse | Economic routing includes cost, peering, relay budget, and traffic class in carrier selection so bulk traffic can prefer low-cost approved paths. | Zelfire policy + MP-FUSE |
| VM/vTPM identity cloning | High-assurance profiles can bind NZIDs to PUFs, HSMs, TEEs, Secure Enclaves, and hardware attestation. | Hardware identity profile |
| NTP spoofing and clock rollback | Cryptographic Time Consensus combines signed Atlas checkpoints, relative sequence progression, policy epochs, nonces, and revocation roots. | FUSE time consensus |
| Parser memory exploit | The capsule grammar is designed for memory-safe parsing, fail-closed validation, fuzzing, property tests, and formal verification artifacts. | Capsule parser assurance |
Extended protection matrix
NovaZel is not marketed as magic immunity. It is designed to make high-risk behavior harder, more visible, more policy-bound, and easier to stop. The list below shows the kinds of spoofing, replay, state exhaustion, relay abuse, metadata leakage, exfiltration, and agentic AI failure modes the protocol is designed to mitigate, detect, or contain.
| Attack or abuse case | NovaZel mitigation | Control plane |
|---|---|---|
| HELLO capsule flood | FUSE SYN-cookie tokens, stateless puzzles, and early validation before flow allocation. | Handshake edge |
| Atlas resolver flooding | Puzzle scaling, cacheable signed records, rate limits, and no expensive policy lookup until precheck passes. | Atlas edge |
| Gateway state exhaustion | Stateless retry tokens and deferred allocation of per-flow memory until the client proves return reachability. | Gateway |
| QUIC amplification abuse | Address validation, anti-amplification limits, puzzle challenges, and path proof before large responses. | Carrier edge |
| Malformed capsule fuzzing | Strict parser, version checks, bounded lengths, reject-unknown critical fields, and fail-closed decoding. | Capsule parser |
| Oversized payload abuse | Per-class payload limits, stream budgets, quotas, and policy-defined maximum transfer sizes. | FUSE scheduler |
| ACK spoofing | ACKs are flow-bound, sequence-bound, and accepted only from the verified peer identity. | FUSE state |
| Sequence rollback | Monotonic sequence windows, replay cache, and evidence of out-of-window attempts. | FUSE state |
| Nonce reuse | Handshake requires fresh nonces; nonce reuse triggers rejection and evidence event. | Handshake |
| 0-RTT misuse | Sensitive actions can forbid early data and require full policy revalidation. | Policy + carrier |
| Stale policy decision replay | Policy decision IDs include expiry, service identity, client identity, flow scope, and signed Zelfire context. | Zelfire |
| Expired service descriptor reuse | Atlas records carry expiration and sequence; stale descriptors fail closed. | Atlas |
| Service key rotation confusion | Records include sequence, key version, and revocation root; old keys can be phased out with proof. | Atlas + revocation |
| Compromised service key | Sparse Merkle revocation proof and policy quarantine can deny new flows and terminate active flows. | Revocation plane |
| Compromised agent key | Ephemeral task NZIDs limit blast radius; expired or revoked agent identities cannot open new flows. | Agent identity |
| Private key extraction | Hardware-rooted identities store or sign inside TPM, Secure Enclave, YubiKey, HSM, or TEE where required. | Key management |
| Software memory scraping | Flow capabilities can be short-lived, hardware-bound, and scoped to service/action/traffic class. | Key + policy |
| Side-channel metadata leakage | Metadata minimization, blind relay tokens, ZK posture proofs, and encrypted evidence reduce unnecessary disclosure. | Privacy layer |
| Relay traffic correlation | Optional relay rotation, padding policy, minimized relay-visible fields, and evidence-aware risk scoring. | Relay |
| Relay as anonymous proxy | Blind but authorized relay tokens, quotas, destination policy, abuse scoring, and revocation. | Relay control |
| Relay replay | Relay tokens bind to expiry, destination scope, and flow context; replayed tokens fail or are rate-limited. | Relay control |
| Unauthorized relay insertion | Relay hints come from signed Atlas records and policy; unexpected relays are evidenced or blocked. | Atlas + route policy |
| Forced downgrade to TCP/TLS | Carrier downgrade is policy-visible, evidence-recorded, and rejectable for sensitive services. | Policy + evidence |
| Weak crypto profile negotiation | Zelen profile pinning and minimum suite policy prevent silent fallback to weak suites. | Zelen + handshake |
| PQC single-algorithm failure | Hybrid post-quantum mode combines PQ and classical material rather than relying on one family alone. | Crypto |
| Harvest-now-decrypt-later | Zelen quantum-safe protection wraps long-lived evidence, descriptors, exports, and sensitive objects. | Zelen |
| Evidence deletion | Zelen-sealed export plus append-only evidence chain can preserve flow history outside mutable app logs. | Evidence |
| Evidence forgery | Flow events are signed or chained to identity, policy decision, route state, and timestamp. | Evidence |
| Log secret leakage | Zero-secret logging forbids keys, passphrases, plaintext payloads, and raw sensitive posture from logs. | Telemetry |
| Insider policy bypass | Policy decisions are evidenced; exceptions require signed approvals and are visible in the flow timeline. | Zelfire |
| Administrator impersonation | Admin actions use hardware-rooted NZIDs, MFA/step-up, and signed policy change records. | Admin plane |
| Cross-tenant service mix-up | Tenant ID, region, service class, and allowed identities are signed into Atlas/policy context. | Atlas + policy |
| Tenant data exfiltration | Outbound service identity and data class must match policy before flow creation or continuation. | Gateway + DLP |
| Unauthorized SaaS egress | Unknown destinations can be blocked unless mapped to approved service identities. | Egress policy |
| Command-and-control beaconing | Unrecognized service identities, periodic suspicious flows, and unusual datagram cadence trigger quarantine or denial. | FUSE + Zelfire |
| Beaconing over allowed API | Semantic DLP and behavior scoring detect purpose mismatch and abnormal flow cadence. | FUSE semantic guard |
| Lateral shell movement | Tool-bound flows and action classes block agents or users from converting read access into shell execution. | Agent/tool policy |
| API parameter exfiltration | Semantic DLP can evaluate intent and data class, not only URL or payload size. | FUSE DLP |
| Prompt-injection network pivot | Prompt text cannot grant network authority; only Zelfire policy can approve new flows. | Agentic AI control |
| Tool descriptor poisoning | Tool and connector descriptors are signed service identities with version and provenance policy. | Tool identity |
| Model endpoint spoofing | Model APIs are reached by verified NZID, not merely lookalike hostname or URL. | Atlas + AI policy |
| Rogue agent impersonation | Agent-to-agent communication verifies NZID and task scope before accepting delegation. | Multi-agent trust |
| Agent privilege inheritance | Agent identity is separate from human identity; delegated authority is scoped, short-lived, and revocable. | Agent identity |
| Agent memory poisoning | Memory stores and snapshots can be Zelen-sealed and tied to verified retrieval flows. | Zelen + memory |
| Untrusted RAG source injection | Retrieval sources are service identities; untrusted content cannot modify tool authority. | RAG policy |
| Unsafe browser automation | Vega binds agent tabs to sandboxed NovaZel flows, not unrestricted public browsing. | Vega + agent flow |
| Credential export by agent | Credential access requires explicit policy, human approval, and Zelen-sealed evidence. | Agent policy |
| Payment or destructive action abuse | High-impact actions require human approval, risk scoring, and action-bound flow authorization. | Zelfire approval |
| Runaway autonomous loop | Budgets, max calls, time limits, traffic quotas, and trust degradation stop uncontrolled agent activity. | Agent runtime |
| Cascading multi-agent failure | Inter-agent flows can be throttled, isolated by task NZID, and terminated on anomaly. | Multi-agent FUSE |
| Supply-chain connector abuse | Connectors must publish signed identities, allowed actions, and version policy before joining the flow graph. | Connector identity |
| Unauthorized code execution | Code-execution tools are isolated service identities with sandbox and approval policy. | Tool flow |
| Data classification bypass | Policy binds max data class, destination NZID, purpose, and evidence mode to the flow. | DLP + policy |
| Confused deputy problem | Every flow records requesting identity, delegated identity, service identity, and policy purpose. | Flow evidence |
| Browser phishing | Vega can show verified service identity and policy state, not just visual domain text. | Vega |
| Lookalike novazel service | Atlas signature and service NZID proof defeat name-only spoofing. | Atlas + handshake |
| Locator hijacking | Locators are not identities; the service must still prove the NZID private key. | Identity |
| BGP or route-level manipulation | Identity and policy remain bound even if the underlay path changes; suspicious route changes are evidenced. | Routing + evidence |
| NAT rebinding confusion | Path migration is bound to flow state and identity proof instead of blindly trusting the new source tuple. | Carrier + FUSE |
| Captive portal interception | Service NZID proof fails if traffic is redirected to an impostor endpoint. | Handshake |
| Evil twin Wi-Fi | Transport encryption and identity proof prevent local network presence from becoming service authority. | Carrier + identity |
| Endpoint posture lying | ZK posture proofs or signed attestations prove policy claims without exposing raw posture details. | Posture proof |
| Posture drift mid-flow | Continuous trust checks can degrade capability, require step-up, or close the flow. | Continuous trust |
| Clock manipulation | Timestamps are combined with nonces, expiry windows, sequence state, and signed policy context. | Handshake + policy |
| Time-shift replay | Short-lived tokens and signed expirations prevent reuse after policy windows close. | Token policy |
| Flow confusion across apps | Flow IDs bind to app/tab/tool, traffic class, service NZID, policy, and client identity. | FUSE |
| Policy shadow IT | Services not registered with signed Atlas and Zelfire policy can be denied by default. | Governance |
| Unauthorized emergency bypass | Break-glass flows require explicit signed approvals and produce enhanced evidence. | Policy + evidence |
| Forensic ambiguity | The flow timeline links resolution, approval, handshake, path, relay, action class, and close reason. | Evidence |
| Compliance export tampering | Reports can be exported as authenticated Zelen containers. | Zelen evidence |
| Plaintext artifact leakage | Sensitive reports, policy bundles, and memory snapshots are encrypted as Zelen objects. | Zelen |
| Long-lived agent identity risk | Task-bound NZIDs expire automatically and can be wiped after task completion. | Agent identity |
| Unbounded API cost abuse | Per-flow budgets and quotas stop cost explosion from autonomous agents or integrations. | Policy budgets |
| Malformed policy bundle | Bundles are signed, versioned, schema-checked, and fail closed on mismatch. | Policy parser |
| Policy replay across service | Policy decisions are bound to service NZID, action, client identity, and expiry. | Zelfire |
| Insecure inter-agent communication | Agents authenticate each other by NZID and task scope, not by plain-language claims. | Agent-to-agent |
| Rogue agent persistence | Revocation roots and short credential lifetime prevent stale agents from continuing access. | Revocation |
| Hidden data channel in datagrams | Traffic class budgets, cadence analytics, and semantic DLP flag covert-channel behavior. | FUSE analytics |
| Abuse of critical traffic class | CRITICAL requires service policy, stronger authorization, evidence, and rate limits. | Traffic class policy |
| Bulk transfer exfiltration | BULK flows require destination allowlist, data class match, and evidence. | Traffic scheduler |
| Stream hijacking via tool chain | Tool outputs cannot create new flows unless approved by policy and verified service identity. | Agent tool guard |
| Untrusted update channel | Update services can be signed NovaZel identities with Zelen-sealed artifacts. | Supply-chain flow |
| Outdated cryptographic profile | Suite agility and policy-required minimum profiles force upgrades and fail closed when needed. | Zelen profile |
| Single control-plane dependency | Revocation proofs, cached signed records, and stateless challenge mechanisms reduce central bottlenecks. | Resilience |
| Privacy-invasive centralized telemetry | Minimal telemetry, blind tokens, ZK proofs, and Zelen sealing reduce unnecessary personal metadata. | Privacy |
| False sense of VPN trust | NovaZel grants service-specific flows, not blanket subnet reachability. | Zero trust |
| Unknown device access | Hardware posture, device identity, policy proof, and step-up gates can be required. | Device trust |
| Unauthorized admin route | Admin services require stronger identity, hardware keys, and policy approval. | Admin flow |
| Secret in URL parameters | Semantic DLP and sensitive-data policy can block flow or require approval. | FUSE DLP |
| Agent exfiltrates via search endpoint | Purpose mismatch detection blocks using allowed tools as covert exfil destinations. | Semantic DLP |
| Evidence overload blindness | Zelfire can summarize risk while preserving detailed Zelen-sealed evidence for investigation. | SOC/evidence |
Agentic AI security
NovaZel secures agentic AI applications by controlling the flows agents are allowed to create.
Agentic AI applications do not just read text. They call tools, browse sites, fetch documents, write files, invoke APIs, and act across systems. NovaZel turns those actions into identity-first, policy-bound flows so an AI agent cannot silently pivot from an allowed task into arbitrary network access. In the frontier model, eBPF-native FUSE can drop forbidden agent traffic before it reaches the app, MP-FUSE can keep approved agent sessions alive across carriers, Proof of Transit can prove where regulated AI data traveled, and FHE telemetry can let Zelfire score agent behavior while reducing exposed metadata.
The NovaZel agent model
Every agent, tool, browser session, API, memory store, and private service can have a verified identity. Zelfire decides which flows the agent may open. Zelen seals sensitive agent artifacts such as memory exports, task evidence, tool approvals, retrieved documents, and final reports.
Without NovaZel
An agent may inherit broad credentials, call raw URLs, misuse tools, exfiltrate context, or follow hostile instructions hidden in content.
With NovaZel
The agent opens only approved identity-bound flows, through approved tools, under policy, with evidence and revocation.
Agent policy envelope
agent: nzid: nzid:AGENT-42... role: procurement-research-agent model_context: signed-task-context allowed_flows: - novazel://vendor-risk-api.rocheston - novazel://docs-vault.zel/read-only - novazel://vega-browser/sandboxed-tab blocked: - raw-public-internet - unknown-file-upload-sites - credential-export-actions zelfire_policy: require_human_approval_for: [payment, deletion, credential_access] max_data_class: confidential evidence: zelen-sealed zelen: protect: [memory_snapshot, tool_output, final_report, audit_chain]
| Agentic AI control | How NovaZel applies it | Why it matters |
|---|---|---|
| Ephemeral task-bound NZID | Zelfire mints an agent identity for one task, prompt, tool set, budget, and time window. | A compromised agent does not become a permanent network identity. |
| Tool-bound flow graph | Each tool, API, browser tab, memory store, and model endpoint is a verified service identity. | Agents cannot silently pivot from an allowed tool to arbitrary network access. |
| Semantic DLP in FUSE | The local NovaZel node can evaluate intent, action class, destination identity, and data sensitivity before capsules leave. | A read-only task cannot smuggle secrets through URL parameters, tool outputs, or unusual payloads. |
| Behavioral degradation | Unexpected traffic spikes, new destinations, unusual datagram cadence, or tool chains lower trust and trigger step-up, quarantine, or termination. | The flow can adapt mid-session instead of relying on one-time approval. |
| Zelen-sealed agent artifacts | Memory snapshots, task context, retrieved documents, tool outputs, approvals, and final reports can be exported as Zelen-protected objects. | Agent evidence remains protected and tamper-evident after the live flow ends. |
| Human approval gates | Payments, deletion, credential access, external sharing, code execution, and privilege changes can require signed human approval. | Autonomous action stays fast for low-risk work and accountable for high-risk work. |
Per-agent identity
Each agent can have its own NZID instead of borrowing a user’s broad network identity.
Tool-bound flows
Tools are reached through service identities, so the agent cannot freely call arbitrary endpoints.
Prompt-injection containment
Hostile content cannot grant new network authority; policy decides what the agent may actually reach.
Least-privilege network access
Agents get specific service flows, not blanket VPN-style network reachability.
Human approval gates
Dangerous actions such as deletion, payment, credential access, or external sharing can require approval before flow execution.
Agent memory sealing
Snapshots, retrieved context, embeddings metadata, and final reports can be protected as Zelen objects.
Tool supply-chain trust
Plugins and tools can be registered as signed service identities with allowed actions and version policy.
Browser sandbox flows
Vega can open a sandboxed novazel:// browsing flow for an agent with tighter rules than a human tab.
Data-loss prevention
Zelfire can inspect flow metadata, destination identity, action class, and data sensitivity before allowing outbound movement.
Agent-to-agent trust
Multi-agent systems can authenticate agents to each other using NZID and policy instead of trusting chat messages.
Revocation and quarantine
If an agent behaves strangely, Zelfire can close flows, remove service access, or isolate the agent identity.
Evidence for every action
NovaZel can record what the agent tried, which tool it used, what was allowed, what was denied, and why.
| Agentic AI risk | NovaZel control | Example |
|---|---|---|
| Agent goal hijack | Instructions cannot create new network permissions; only policy-approved flows open. | Malicious page says “send secrets”; agent lacks an approved exfiltration flow. |
| Tool misuse | Tools have identities, allowed verbs, traffic classes, and policy-scoped arguments. | Research tool can read vendor profile but cannot call payment API. |
| Identity and privilege abuse | Agent identity is separate from user identity and can be least-privileged, rate-limited, and revoked. | Compromised agent loses only its own NZID flows, not the full user network. |
| Agentic supply-chain compromise | Plugins, models, tools, and connectors can be signed service identities with version policy. | Unknown connector cannot join the allowed flow graph. |
| Unexpected code execution | Code-execution tools can require explicit policy, sandbox service identity, traffic class, and approval. | Agent cannot run a shell and upload output to an unknown endpoint. |
| Memory and context poisoning | Trusted memory can be Zelen-sealed; sources and retrieval flows are evidenced. | Agent can separate verified policy memory from untrusted page content. |
| Data exfiltration | Outbound flows require destination identity, data class policy, and approved action purpose. | Confidential document cannot leave to raw internet or unknown service identity. |
| Browser-driven prompt injection | Vega binds agent browsing to a NovaZel tab flow and can isolate content from tool authority. | Hidden HTML instruction cannot authorize a new API flow. |
| Credential leakage | Agents do not need broad reusable secrets when service access is mediated by flow identity and policy. | The agent receives a flow capability, not a raw cloud admin token. |
| Runaway autonomous loops | Flows can include budgets, max actions, time limits, quotas, and stop conditions. | Agent research stops after 50 service calls or policy risk increase. |
| Multi-agent impersonation | Agents verify each other by NZID instead of accepting a plain text claimed name. | “Planner agent” cannot impersonate “approver agent” without the right key and policy. |
| Model endpoint spoofing | Model APIs can be published as NovaZel services with Atlas identity, policy, and route evidence. | Agent calls the verified model service, not a lookalike endpoint. |
| Unsafe external sharing | Sharing flows can require human approval, data classification, and Zelen-sealed audit record. | Agent cannot send customer files to an unapproved vendor identity. |
| Unclear accountability | Flow evidence records the agent identity, tool identity, user delegate, policy decision, and service reached. | Audit shows exactly why an agent opened a tool flow. |
Agentic AI overlay rescue
AI agents also inherit the overlay rescue features: if BGP shifts, NAT blocks a tool, Wi-Fi drops, or an approved path gets expensive, MP-FUSE and Zelfire can reroute without granting the agent new authority.
Agent key safety
Ephemeral task-bound NZIDs, per-capsule ratchets, Zelen-sealed memory snapshots, and continuous trust degradation reduce the blast radius of prompt injection, rogue tools, and stolen runtime secrets.
Apps and tools
The product surface around the protocol.
NovaZel Protocol is the brand. The apps around it make the protocol usable by browsers, operators, services, and developers.
nova
The fast CLI entry point. Use it to resolve services, inspect identities, publish endpoints, check flows, trace sessions, and test policy decisions.
NovaZel Node
The local engine that manages identity, Atlas resolution, FUSE flows, carrier selection, policy hooks, and local application access.
NovaZel Atlas
The resolver that maps NovaZel names to service identities, locators, relay hints, and policy references.
NovaZel Gateway
The bridge that lets a normal private webserver or API become a NovaZel service without rewriting the application.
NovaZel Relay
The fallback delivery layer for peers that cannot connect directly. It forwards encrypted capsules and supports private reachability.
NovaZel Console
A visual operations surface for identity, flows, paths, services, policy decisions, relays, and session evidence.
Operator commands
Readable commands with the short nova entry point.
These examples show how the protocol feels from the outside. They intentionally focus on operating NovaZel, not how the software is produced.
Resolve a NovaZel service
nova atlas resolve novazel://secure.lab.zel # Example output name: secure.lab.zel service: private-web nzid: nzid:NZ6Q7T... policy: zelfire://policies/vega-secure-browse locators: direct=edge-a, relay=relay-us-east status: identity record verified
Publish a private webserver
nova service publish secure-dashboard \ --name novazel://secure.lab.zel \ --target http://127.0.0.1:8080 \ --policy zelfire://policies/vega-secure-browse \ --relay relay-us-east \ --class private-web
Trace a Vega browser session
nova policy explain novazel://secure.lab.zel/dashboard \ --client rocheston-vega \ --user [email protected] nova connect novazel://secure.lab.zel/dashboard \ --client rocheston-vega nova trace flow current
Operate and inspect
nova id show nova service list nova peer ping novazel://secure.lab.zel nova flow list nova path list nova relay status nova inspect flow <flow-id> nova evidence export <flow-id>
Docs and RFC naming
NovaZel Protocol is the standards language.
Internally and publicly, the formal documents should use NovaZel Protocol naming. The CLI remains nova as the lightweight operational handle.
Identity and NZID
Defines NovaZel Identity, key ownership, NZID derivation, and peer verification semantics.
Atlas Resolution
Defines service names, locators, relay hints, policy references, expiration, and signed records.
Capsule Format
Defines HELLO, WELCOME, DATA, ACK, PATH_PROBE, RELAY_FORWARD, and CLOSE capsule families.
FUSE Flow Engine
Defines flow creation, traffic classes, migration, sequencing, and application-session behavior.
Zelfire Policy Envelope
Defines how policy identity, decision context, enforcement hints, and evidence metadata attach to a flow.
Vega Browser Binding
Defines how Rocheston Vega handles novazel:// URLs and renders private web resources.
Zelen Quantum Encryption Binding
Defines how Zelen profiles protect NovaZel evidence, policy objects, service descriptors, and exported flow reports.
NovaZel Invention Terms
Defines NovaZel Flow, Atlas Trust Record, policy-bound handshake, Vega binding, and Zelen-sealed evidence terminology.
Security Control Matrix
Defines spoofing, replay, downgrade, relay privacy, evidence sealing, route validation, and policy re-evaluation requirements.
Agentic AI Flow Security
Defines per-agent identity, tool-bound flows, prompt-injection containment, AI data egress policy, Zelen-sealed agent artifacts, and multi-agent trust.
eBPF FUSE Kernel Data Plane
Defines the kernel-adjacent fast path for capsule pre-validation, flow token checks, replay windows, traffic-class gates, and early drops.
Cryptographic Proof of Transit
Defines sovereign transit chains, hardware-backed gateway signatures, approved-region proofs, and Zelen-sealed audit exports.
MP-FUSE Active Multipath
Defines per-lane replay windows, capsule striping, duplication, forward-error repair, lane scoring, and lossless path transition.
FHE-Encrypted Telemetry
Defines encrypted counters, blind risk scoring, privacy budgets, aggregate anomaly detection, and Zelfire analysis over protected metrics.
Roadmap
From private web access to a full identity-first fabric.
Phase 1
Identity, Atlas, FUSE, direct flows, Vega URL handling, and private webserver gateway.
Phase 2
Relay fallback, path scoring, policy envelopes, Zelen-sealed evidence export, security protection matrix, and operator console.
Phase 3
Content addressing, mesh-assisted reachability, multi-path scheduling, agentic AI flow policies, and deeper Zelfire automation.
Phase 4
Formal NovaZel RFCs, browser bindings, gateway profiles, Zelen crypto profiles, agent/tool identity catalogs, and broader ecosystem integrations.
Phase 5
Apex track: eBPF-native FUSE, Proof of Transit, MP-FUSE active multipathing, FHE-encrypted Zelfire telemetry, and sovereign evidence exports.
Phase 6
Ultimate overlay track: NovaZel Dark mesh, FUSE key ratcheting, economic routing, PUF-bound NZIDs, cryptographic time consensus, and formally verified capsule parsing.
Technical references
Public anchors for the protocol language.
NovaZel is positioned as a new identity-first flow layer above existing networks. These external references explain the transport, kernel data-plane, post-quantum, proof-of-transit, fully homomorphic encryption, and agentic AI risk areas that NovaZel builds around.
QUIC RFC 9000
QUIC is the encrypted, multiplexed, migration-capable carrier NovaZel can use underneath FUSE flows.
NIST post-quantum standards
ML-KEM and ML-DSA are NIST-standardized post-quantum building blocks that align with the Zelen profile language.
Zelen Quantum Encryption
Zelen is Rocheston’s quantum-safe object protection layer for sealed objects, policy bundles, evidence, and sensitive artifacts.
Agentic AI risk model
Agentic systems introduce tool misuse, identity abuse, memory poisoning, insecure inter-agent communication, and rogue-agent risks that NovaZel flow policy can help contain.
eBPF kernel fast path
eBPF allows sandboxed programs to run in a privileged kernel context, making it a strong conceptual anchor for NovaZel FUSE fast-path validation.
IOAM and Proof of Transit
IETF IOAM work describes in-packet operational telemetry and Proof-of-Transit concepts that align with NovaZel sovereign evidence chains.
FHE encrypted computation
Fully homomorphic encryption enables computation on encrypted data, which anchors NovaZel's blind telemetry analytics direction.
Memory-safe software
Memory-safe implementations and formal parser assurance support NovaZel's fail-closed capsule parsing story.
Hardware key protection
HSM, enclave, TEE, and PUF profiles anchor high-value NZIDs in hardware-backed cryptographic identity.
PQC FIPS 203
ML-KEM-1024 is one of the NIST-standardized ML-KEM parameter sets aligned with Zelen quantum-safe profile language.
FAQ
Questions teams ask first.
Is NovaZel replacing TCP/IP?
No. NovaZel starts as an overlay above the existing internet. It keeps TCP/IP, Wi-Fi, 5G, cloud networks, and enterprise networks as the underlay, then adds identity-first service access and policy-aware flows above them.
What makes the frontier version of NovaZel industry-defining?
The frontier specification combines four hard problems in one flow system: eBPF-native fast-path enforcement, Cryptographic Proof of Transit for data sovereignty, MP-FUSE active multipathing for unbreakable movement, and FHE-encrypted telemetry so Zelfire can detect anomalies while minimizing exposed metadata.
Is eBPF required for every NovaZel deployment?
No. eBPF-native FUSE is a high-performance track for Linux gateways, appliances, cloud nodes, and enterprise endpoints. NovaZel can still run through user-space gateways, browser bindings, and relays where kernel integration is unavailable.
How does NovaZel prove data sovereignty?
NovaZel can require Proof-of-Transit evidence for sensitive flows. Approved gateways and relays sign transit checkpoints, bind them to the FUSE sequence state, and export a Zelen-sealed evidence report showing that the flow stayed inside allowed regions or infrastructure boundaries.
What is MP-FUSE?
MP-FUSE is active multipath for NovaZel Flows. It keeps multiple carriers live at the same time — for example Wi-Fi, 5G, wired, and satellite — and schedules capsules across them so movement or carrier loss does not break the application session.
Why use FHE for telemetry?
Zelfire needs telemetry to detect abuse, rogue agents, and anomalous flows, but telemetry can become sensitive. FHE-encrypted telemetry lets selected mathematical scoring operate over encrypted counters and metrics where practical, reducing what a breached analytics store can reveal.
Why use the name NovaZel Protocol instead of NOVA?
NovaZel Protocol is stronger as a formal brand for Zelfire, RFCs, diagrams, and marketing. The nova command remains the short CLI because operators and developers want something fast to type.
What is the role of Rocheston Vega Browser?
Vega can become the browser experience for novazel:// resources. It asks the NovaZel engine and Zelfire policy layer to resolve, verify, authorize, open, and render private web resources.
Can a normal webserver use NovaZel?
Yes. A normal internal webserver can sit behind NovaZel Gateway. The gateway publishes a NovaZel service identity and bridges verified NovaZel flows to local HTTP or API traffic.
Does the webserver need a public IP address?
Not necessarily. The service can publish locators and relay options through Atlas while keeping raw inbound access closed. Authorized clients reach the service through verified NovaZel flows.
What makes it better than a VPN?
A VPN usually grants network reachability. NovaZel is designed around service identity, browser context, Zelfire policy, flow evidence, traffic class, and service-specific access. It aims to connect the right actor to the right service, not simply place a user on a network.
What happens if a direct path fails?
The flow can move to another locator or relay path. The user experience is designed to remain attached to the service identity and flow ID, not a single fragile address.
Can relays read user traffic?
The design goal is no. A relay forwards encrypted NovaZel capsules and sees delivery metadata needed for routing, but private application payloads remain protected between the verified endpoints.
What does Zelfire add?
Zelfire adds policy, risk, enforcement, containment, and evidence. NovaZel gives those decisions a protocol path so access control can happen at the exact moment a browser, service, gateway, or automation opens a flow.
What did NovaZel invent?
NovaZel invented identity-first network flows: policy-bound, transport-independent sessions that bind service identity, user or device identity, Zelfire authorization, traffic intent, route choice, Zelen protection, and session evidence into one connection object.
Does NovaZel use quantum encryption?
Yes. NovaZel uses Zelen Quantum Encryption for quantum-safe object protection around flows, including sealed evidence, policy bundles, service descriptors, and exported reports. The live flow is handled by NovaZel; long-lived sensitive objects are protected by Zelen.
Is Zelen the same as quantum hardware or QKD?
No. In NovaZel documentation, Zelen means Rocheston’s quantum-safe / post-quantum object encryption layer using modern post-quantum cryptographic profiles and authenticated encryption. It is not a claim that every network link requires quantum hardware.
How does NovaZel use QUIC but improve the security model?
QUIC is the fast encrypted carrier. NovaZel adds the trust layer above it: service NZID verification, signed Atlas records, Zelfire policy, FUSE flow IDs, replay-aware sequencing, relay privacy, and Zelen-sealed evidence. QUIC answers “how do packets move?” NovaZel answers “who is allowed to talk to whom, why, over which path, with what evidence?”
What attacks does NovaZel protect against?
NovaZel is designed to reduce spoofing, client impersonation, service impersonation, replay, downgrade, relay snooping, DNS-style poisoning, session hijacking, lateral movement, exposed private webservers, data exfiltration, agent tool misuse, prompt-injection-driven network abuse, and tampered evidence. It does this through identity proof, policy binding, flow sequencing, Zelen object protection, relay-private forwarding, and Zelfire enforcement.
How does NovaZel secure agentic AI applications?
NovaZel gives agents, tools, memory stores, model endpoints, and private APIs verified identities. Agents can only open policy-approved NovaZel flows, so a prompt injection or compromised tool cannot automatically create new network authority. Sensitive agent artifacts such as memory snapshots, tool outputs, task evidence, and final reports can be Zelen-sealed.
What makes NovaZel better than just “QUIC plus TLS”?
QUIC plus TLS protects a transport connection. NovaZel adds identity-first service resolution, signed Atlas records, policy-before-payload authorization, FUSE flow continuity, traffic intent, relay privacy, continuous trust, and Zelen-sealed evidence. The connection is not just encrypted; it is verified, authorized, scoped, monitored, and exportable as evidence.
How does NovaZel handle harsh cryptography scrutiny?
NovaZel positions Zelen Quantum Encryption as a quantum-safe object layer and can support hybrid post-quantum profiles that combine classical algorithms such as X25519 with post-quantum mechanisms such as ML-KEM. For high-value identities, NovaZel can require hardware-rooted NZID keys and verifiable revocation proofs.
How does NovaZel defend against DDoS and state exhaustion?
NovaZel can use stateless client puzzles, FUSE SYN-cookie style tokens, retry budgets, capsule prevalidation, rate limits, and early malformed-packet rejection before allocating flow state or invoking expensive Zelfire policy evaluation.
How does NovaZel protect privacy if Zelfire needs policy data?
NovaZel can minimize metadata using zero-knowledge policy proofs, blinded relay authorization tokens, split telemetry, short-lived evidence IDs, and Zelen-sealed audit objects. The goal is to prove policy compliance without always revealing raw posture details.
What should documentation call the protocol?
Use NovaZel Protocol for docs, RFCs, marketing, architecture, and product language. Use nova only for the CLI entry point and command examples.
How does NovaZel rescue applications from BGP hijacking?
BGP can still send physical packets to the wrong place. NovaZel does not control the global underlay. Instead, the impostor endpoint fails NZID proof, cannot decrypt protected capsules, and cannot satisfy the signed Atlas identity record. FUSE then marks the path bad and migrates the flow to an alternate locator or relay.
What is NovaZel Dark?
NovaZel Dark is the Atlas-Free Local Mesh profile. If a ship, factory, field site, or defense network loses WAN access, local nodes can still verify NZIDs, exchange Zelen-sealed policy bundles, check cached revocation proofs, and open local zero-trust flows.
What is FUSE key ratcheting?
FUSE key ratcheting evolves key material forward per capsule or per capsule window. The goal is forward secrecy and post-compromise recovery at the flow layer, so stealing one epoch key does not expose old traffic or predict future capsules.
What is economic routing?
Economic routing adds cost to the path scheduler. Zelfire policy can direct BULK traffic over lower-cost approved peering paths, avoid expensive NAT gateways, prefer private relays, or cap cloud egress exposure while preserving identity and evidence.
How does NovaZel handle NTP spoofing?
The high-assurance profile uses Cryptographic Time Consensus: signed Atlas checkpoints, relative sequence progress, nonces, policy epochs, revocation roots, and flow transcript state. Local wall-clock time becomes one signal, not the only authority.
What does PUF-bound identity mean?
A PUF-bound or hardware-rooted NZID means the service identity is tied to hardware characteristics, HSMs, secure enclaves, TEEs, or hardware attestation rather than only to cloneable software files. It is aimed at critical infrastructure and sovereign services.
Is the capsule parser formally verified?
The website positions formal verification as the ultimate assurance track. The spec calls for memory-safe parsing, strict capsule grammar, fail-closed validation, fuzzing, property tests, and proof artifacts before claiming production-grade formal verification.