Ownership model
One Neutron canister belongs to one human in the product model. The kernel does not and cannot prove that relationship: it enforces a flat set of full-trust authorized principals. Treating every entry as a credential of the same owner is therefore a deployment assumption, not an enforced one-human invariant.
An instance has no users, no teams, no roles, no invitations, and no per-user data partitions. Its workspaces, apps, backend memory, files, resident processes, external connections, credentials, and settings all belong to that one person. Any authorized principal reaching that canister is reaching the owner's state.
Two layers of "owned"
Runtime authority: the authorization set
The kernel keeps a flat set of authorized principals. The generated wrapper asserts membership in that set before running any ordinary app method. Every entry is a full-trust credential of the same owner — a browser identity, a recovery identity, a trusted CLI tool.
They are not user accounts. Neutron's UI is expected to present the set as owner access and recovery credentials, and app authors are explicitly asked not to build per-principal user models on top of it.
Platform authority: IC controllers
Separately, the canister has IC management controllers. Controller status is strictly more powerful than kernel authorization: a controller can replace code, change settings, stop, or delete the canister outright, entirely outside Neutron's rules.
Normal provisioner and dispenser final states include the Neutron canister as its own controller — that is what makes self-upgrade possible — and Settings refuses to remove it. An external controller can still change that list outside kernel rules. An owner may add an external recovery controller through Settings.
Technical principals are not users
Technical principals also appear during deployment and recovery:
- The dispenser temporarily installs and seeds a hosted instance. Arming the one-time activation hash removes it from kernel authorization; completing the handoff removes it from the IC controller list too.
- The canister itself remains an IC controller so that it can invoke
install_codein upgrade mode against itself and manage recovery controllers. - A provisioner's deployment identity is an initial controller and an authorized kernel credential on operator-created instances unless the operator later changes those lists.
None is an additional Neutron user, and none should surface in app UI as one.
Getting authorized
When you open your canister, the kernel frontend logs in through Internet Identity and asks the backend whether the resulting principal is authorized.
- If it is, the kernel fetches the certified Candid interface for the canister and builds its authenticated client.
- If it is not, the kernel shows a blocking screen displaying the exact Neutron-origin principal with a copy action.
How that copied principal gets added depends on how the canister was created:
| Creation path | Adding the owner principal |
|---|---|
| Provisioner (operator) | An already-authorized deployment identity adds it. |
| Dispenser (hosted) | The browser creates a one-time activation code before payment. The dispenser stores only its hash in the new Neutron and retires its own authority. After Internet Identity login, the activation link submits the code once; a valid code atomically authorizes the actual signed caller and is destroyed. |
Once one identity is in, Settings can add further recovery principals and IC controllers. A current IC controller also has a narrow public recovery method that can authorize a replacement owner or tool principal after the backend verifies live controller status.
What this means when you design an app
- Do not model users. There is one. Storing "the current user's" data means storing the owner's data.
- Do not treat a principal as an identity boundary. Two authorized principals are the same person; branching on which one called is a credential-management concern at most.
- Cross-Neutron interaction is inter-canister, not multi-user. If your app talks to another person's Neutron, that is a public protocol between two separately owned computers. See public ingress.
Known gaps
The current implementation does not distinguish the human owner from installer or technical authorities inside the authorization set, and does not label entries. There is no ownership-transfer flow or automatic credential backup. The dispenser has no delete or registry-removal API, and it cannot repair a completed instance after retiring its authority. Losing the locally stored provisioning key or activation code before activation has no server-side human recovery path; the activation code is a bearer credential until it is consumed.
These are tracked in Open questions.