Threat model

What this page is

A threat model is a statement of assumptions, not a list of defences. This page names the parties UniNet places inside its trust boundary, the parties it treats as adversarial, the places where an authorization decision refuses rather than guesses, and the attack classes the network does not address today. Read it before you decide which class of workload belongs here, because the answer for a research pilot and the answer for a regulated production system are different answers.

UniNet is several primitives composed into one network: identity, delegated authority, private routing, container execution, settlement. Each carries its own boundary. Collapsing them into a single verdict of secure or insecure discards exactly the information you need to make the decision.

The boundary

                      OUTSIDE  —  treated as adversarial
     ┌──────────────────────────────────────────────────────┐
     │  other tenants sharing a host                         │
     │  any single relay on a private route                  │
     │  other nodes, and the schedulers that reach them      │
     │  a caller presenting a delegated right                │
     │  a counterparty asserting who it is                   │
     └──────────────────────────────────────────────────────┘
                                │
     ═══════════════════════════╪══════════════════════════════
                                │
     ┌──────────────────────────────────────────────────────┐
     │  the private key material of an identity              │
     │  the node process on the machine                      │
     │  the host kernel and hypervisor                       │
     │  the host operator holding root            ← note     │
     └──────────────────────────────────────────────────────┘
                       INSIDE  —  assumed honest

The fourth line inside the boundary is the one most readers will want to move outward. Today it cannot be moved. Isolation between workloads is enforced by the container and kernel boundary of the machine, and whoever administers that machine sits above it. If the party running your workload is in your adversary set, the model on this page does not cover your case.

Trusted, not trusted, out of scope

| Element | Position | What follows from it | | --- | --- | --- | | Private key material of an identity | Trusted | Control of the key is control of the identity. Any recovery mechanism is, structurally, another key held by someone. | | Key custody on disk and in memory | Trusted | Signing keys live in software on the machine that holds them. A host compromise is a key compromise. | | Host kernel, hypervisor, node process | Trusted | The isolation boundary between co-tenants is a kernel boundary, not a silicon one. | | Host operator with root | Trusted | The operator can observe the workload their machine runs. This is a property of the model, not an oversight in a deployment. | | Another container on the same host | Not trusted | Resource limits and container boundaries bound what a co-tenant can consume and reach. | | Any single relay on a private route | Not trusted | Routing is designed so that no one relay holds the complete relationship between user, service and hosting location. | | A caller presenting a delegated right | Not trusted beyond that right | Authority is scoped at issue and revocable after it, with revocation cascading to rights derived from it. | | A claimed human or legal identity | Not trusted | A supervisor relationship is a cryptographic association between keys. It asserts that one key answers for another, and nothing about who holds either. | | Attacks mounted by the operator against the workload | Out of scope | There is no hardware-backed confidential computing path to place the operator outside the boundary. | | Regulated key-management requirements | Out of scope | Deployments whose procurement requires hardware-backed custody do not have a path here yet. | | Cross-chain settlement finality | Out of scope | Do not place value on a cross-chain path you cannot afford to have stranded. | | Third-party assurance | Out of scope | The properties described across this documentation are design intent written to be read and tested. They are not something to cite in a control questionnaire. |

Where the network refuses

Some authorization paths deny by default when they cannot resolve the question they were asked. A request that cannot be positively authorized is refused rather than admitted on the assumption that refusal would be inconvenient. A denied operation on one of those paths is the model working, not a fault to file.

That is a property of particular paths, and it should not be generalized. UniNet does not claim that every authorization path in the system fails closed. When you are evaluating a specific flow, the useful question is narrow: on this path, what happens when the authorization decision cannot be resolved — and have you tested it rather than assumed it.

What the network does not decide for you

The model above stops at the edge of the network's own responsibilities. Outside it sit the physical security of a machine, the correctness of the code you deploy into a container, the soundness of the delegation policy you write, the jurisdiction your chosen nodes sit in, and the operational discipline of whoever holds your keys. None of these are made safer by the protocol, and a design that leans on the protocol to absorb them will not behave the way you expect.

How it composes

Identity establishes who an actor is, in the narrow sense of which key answers for it. Delegated authority bounds what that actor may do and allows the grant to be withdrawn. Private networking bounds what any single intermediary observes about the relationship between a user and a service. Execution bounds what a workload consumes and reaches on the machine running it.

Each of the four narrows one class of loss. None of them substitutes for another, and the composition is not stronger than the weakest boundary a given flow actually crosses. Trace your flow through all four before concluding what it is exposed to, and check the subsystem grades on build status for each primitive the flow depends on.