Security & Trust Model

Why this document exists

Giving an AI agent access to real test hardware raises a different question than giving it access to a shell: what happens when it's wrong, and who can prove what actually happened. This document describes how Plotune Nexus establishes device ownership, where cryptographic trust lives, what a degraded-access session can and cannot do, and which parts of the current design are still being hardened. Nothing below is a roadmap promise; it describes the shipped behavior as of this writing, with open items marked as open.

Device identity and ownership

Ownership is bootstrapped on the device itself, not issued from the cloud.

1. During installation, the device generates and stores its own keypair locally.
2. The device registers public identity metadata (device ID, hardware ID, MAC address, public key) with Plotune's cloud router. This registration establishes durable identity, not ownership.
3. An operator opens the device's local UI and signs in with a Plotune account.
4. The first verified login on a new device is automatically promoted to device owner. There is no separate claim-code flow: signing in first is what establishes ownership.
5. The owner is guided into a short setup review covering delegated access, a local recovery password, and the redirect-URI allow-list used for MCP OAuth clients.

Trust boundaries

• The device's private key never leaves the device. The router stores only the public half plus live route and verification state.
• User authentication is delegated to an external identity provider, not reimplemented by Plotune.
• Ownership authority stays local. Even Plotune's own cloud router cannot silently reassign a device's owner.
• The installer can register a device's identity before any owner account exists. This is deliberate, and is what makes the closed-network provisioning flow below possible.

What a degraded (local-recovery) session can and cannot do

If an owner's Plotune account can't sign in but the device is still reachable, a previously-configured local recovery password grants degraded local access. This path exists specifically for closed-network and connectivity-loss scenarios, not as a general-purpose login method: it only works after a device already has an owner, and it authenticates as that same owner at reduced privilege, not as a separate identity.

A session opened this way cannot:

• change delegated access or ownership,
• change onboarding state,
• change the local recovery credential itself,
• issue new device-verification tokens, or
• change OAuth trust settings, generate manual MCP bearer tokens, or reveal a saved app secret.

To do any of those, the owner has to sign back in with their actual Plotune account. The degraded path is deliberately narrower than the full owner session, not an equivalent backdoor.

Agent access: bounded operations, not shell access

Nexus does not give an MCP client a shell on the device. It exposes a fixed set of typed tools (record_can, read_xcp_calibration, open_uart_session, and so on; the full current list is in the MCP Tools & API Reference) plus a small set of read-only resources for current-state reads. An agent can only invoke the operations the API exposes; it cannot run arbitrary commands on the host.

Two authentication paths exist for reaching that tool surface:

• OAuth, the preferred path, which keeps redirect, consent, and client-registration behavior on a standard, auditable surface.
• A manual bearer token, generated by the owner from the device's Security page, as a fallback for MCP clients that can't complete an OAuth flow. Manual token generation is itself one of the actions blocked in a degraded local-recovery session (see above), so minting a new agent credential always requires the owner's real identity.

What's still hardening

Stated directly, because a security document that only lists strengths isn't a security document:

• The device runtime currently runs with broad host privileges. Narrowing this to explicit, minimal device capabilities is ongoing work, not finished work.
• Offline trust policy for a degraded cloud router is not yet fully defined. Local operation continues (see Data Handling & Deployment Model for exactly what still works while air-gapped), but the formal policy for what "local trust" means when the router is unreachable is an open item.
• Bring-your-own-cloud storage credentials are intended to be short-lived or delegated through presigned operations, not stored broadly on the device. This is a stated design constraint the team is holding itself to, not yet an independently audited guarantee.

References

• Device Claim Flow and Closed-Network Provisioning are internal engineering documents this page summarizes; the closed-network operator checklist is public in Data Handling & Deployment Model.
• MCP authorization model: Model Context Protocol specification, Authorization
• OAuth 2.0 framework underlying Nexus's device OAuth flow: RFC 6749