AI NetShell Threat Model

Target: AI NetShell Windows desktop app, website account handoff, account authority, entitlement broker, hosted-AI broker, and governed AI write path.

This document is a technical risk assessment, not a warranty, certification, service-level agreement, regulatory representation, or contractual security commitment. A statement from this document becomes a public or contractual commitment only if Packet 365 expressly adopts it in the applicable published policy or a signed agreement. Incidents can occur despite the controls described here.

1. Security objective

AI NetShell is a network terminal with an AI agent. The desktop host, not the model, owns native SSH and the live device session. The core objective is to keep untrusted model output from becoming an unreviewed network-device write while protecting account/device credentials and limiting off-box exposure of network data.

For network configuration data, the intended and defensible boundary is:

No background configuration upload, and no standing hosted copy of your network. AI analysis sends only the redacted command output you trigger, and only when you run it.

The AI request also contains the operator's question and the conversation, tool, and instruction context required to perform the requested analysis. Hosted AI passes through the AI NetShell Cloudflare broker before the upstream LLM.

2. Assets

| Asset | Security property | Where it exists | |---|---|---| | Network-device credentials | Confidentiality; use only for the operator-requested connection | OS credential store or selected authentication source; resolved by the desktop host for native SSH/other transports | | Account device credential (adc1) | Confidentiality, integrity, revocability, replay-safe rotation | Full credential in the OS credential store and in account-service requests; hashes plus bounded recoverable rotation/replay material in account authority storage | | Entitlement token (aet1) | Authenticity, integrity, expiry, correct audience/device/account binding | Signed by the broker; stored in OS credential slots; presented to the hosted broker | | Broker and account signing/routing secrets | Confidentiality and controlled rotation | Cloudflare Worker secret stores; public verification keys embedded in the desktop app and broker overlap set | | AI command/write path | Only permit-listed, human-approved governed changes reach device egress | Rust host, permit-policy crate, typed approval token, governed-write state machine | | Device output and configuration evidence | Confidentiality and integrity; redact before model egress | Live scrollback, local redacted snapshots/history/audit, user-triggered LLM requests | | Rollback and verification state | Integrity, freshness, device/session binding, crash recovery | Local attempt journal, rollback handles, snapshots, sealed verification state | | Account and entitlement records | Integrity, availability, privacy | Clerk-linked account authority, Lemon Squeezy-derived entitlement authority, credit ledger |

3. Adversaries and failure modes

A malicious or compromised network device that returns crafted banners, terminal escapes, prompt-injection text, malformed output, or misleading verification evidence.
A malicious, compromised, or simply mistaken AI model that proposes unsafe commands, fabricates success, tries to broaden scope, or follows instructions embedded in device output.
A network attacker between the desktop, account service, hosted broker, LLM provider, or network device.
A stolen adc1 credential or aet1 token.
A compromised account, social identity, Clerk session, Lemon Squeezy event source, Cloudflare Worker secret, or broker signing key.
A compromised Tauri webview, frontend dependency, update, or workstation process trying to invoke privileged host commands.
A local attacker with access to the user's Windows session or OS credential store.
A well-intentioned operator who approves the wrong diff, imports an overbroad BYOP policy, pastes commands into the unrestricted terminal, or misunderstands an incomplete verification result.
Availability and consistency failures: device disconnects, concurrent writers, stale sessions, filesystem failure, clock rollback, partial credential rotation, provider outage, or broker/account-service outage.

Out of scope for an absolute product guarantee are a fully compromised operating system or kernel, a malicious signed build/release key, a compromised production signing secret, physical access to an unlocked workstation, and the internal security of third-party providers. These remain business risks even when outside an individual control's design scope.

4. Trust boundaries

Human ↔ desktop UI. The human can use an unrestricted terminal. AI governance applies to AI-originated actions, not to the operator's own keystrokes.
Webview ↔ Rust/Tauri host. The webview requests actions; the host owns secrets, policies, SSH, state binding, egress, audit, and verification.
Model ↔ host tools. Model text and tool calls are untrusted. The model receives no general SSH socket or credential-retrieval tool.
Desktop ↔ network device. Native SSH uses the Rust transport and host-key trust/checking. Device output is untrusted input.
Desktop ↔ LLM. User-triggered questions and redacted context leave the workstation. Your own AI (an Anthropic key or a ChatGPT sign-in) goes directly to Anthropic or OpenAI; hosted AI goes through the AI NetShell broker and then upstream.
System browser/Clerk ↔ account worker. Clerk sign-in remains website-side. The desktop receives a short-lived enrollment grant; no Clerk SDK or Clerk session is placed in the app trust path.
Desktop ↔ account worker. The app presents adc1 to refresh its credential and obtain a broker-signed aet1 token.
Account worker ↔ broker. The account worker passes only account/device/generation and sanitized display-label facts into token minting. The broker resolves its own entitlement projection.
Desktop ↔ hosted broker. The app treats only a valid AI NetShell-signed aet1 token, with pinned issuer/audience/version/algorithm/key ID and valid time/identity claims, as account entitlement. The hosted broker independently verifies token signatures and mutable entitlement state before spend.
Lemon Squeezy ↔ entitlement authority. Signed purchase/subscription/license webhooks drive entitlement and credit state. Billing identity is kept separate from network-device identity and configuration data.

5. The governed-write enforcement engine

The write safety story is an enforcement engine in the host, not a prompt asking the model to behave.

Phase 1: deny-by-default code and policy

Every proposed governed-write statement is checked in Rust before it can become an executable approval object:

the shipped vendor profile must explicitly enable governed writes;
each line must be one statement, with separator and sequence-shape checks;
the command must not match the in-code dangerous/escape floor;
shipped and user-added block rules win over allow rules;
the statement must match write_allowed; no match means deny;
the full sequence is checked for context changes that could change a line's meaning; and
phase 1 is run again at apply time against the current policy and vendor/session binding.

BYOP overlays are additive. They may extend the allowed surface for a shipped write-enabled profile, but they do not remove shipped blocks, change the shipped writes_enabled value, or replace the immutable in-code escape floor. An allow-all overlay therefore cannot authorize floored reload, erase, file-mutation, shell, scripting, or equivalent abbreviated escape commands.

Phase 2: human diff approval

Phase 1 alone does not write. The operator must review the target, intent, before/after diff, exact statements, rollback preview, and lockout/feasibility warnings, then explicitly approve. Only this host approval path constructs the typed ApprovedChange object that can reach governed egress.

The model cannot click the approval control, mint ApprovedChange, change the approved statements after approval, or provide its own “approval” string. At apply time the host re-runs phase 1, re-resolves the vendor and live device/session binding, and derives the bytes to send from the approved statements. A mismatch between the approved token and the apply plan fails closed.

Snapshot, rollback, and verification

Before applying a supported change, the host captures and redacts the relevant baseline and prepares the vendor-specific rollback anchor or timed-revert mechanism. It journals lifecycle state before egress, holds a fenced per-device write lease, revalidates preconditions immediately before send, and records outcomes.

After device acknowledgement, a host-owned verification driver compares fresh evidence with the sealed expected result. Failure, incomplete evidence, disconnect, or uncertainty is represented as such; it is not converted into success. Rollback commands are re-derived/revalidated and use the same bound egress controls. If the audit record cannot be written after apply, the host attempts the defined force-revert behavior and records whether the revert was clean, failed, unknown, or left to a device timer.

Rollback is a recovery mechanism, not a promise that every outage or partial device failure can be automatically reversed. A dead management path, device crash, concurrent administrator, unsupported vendor behavior, or failed rollback anchor can prevent or complicate recovery.

6. What an attacker cannot do through the intended paths

Subject to the residual risks in section 8:

The model cannot self-authorize a governed write. Model output is only a proposal; the host's typed approval path requires the operator's phase-2 action.
A permit-list miss cannot “default allow.” Governed writes require an explicit match, and blocks win.
BYOP cannot remove the immutable floor or turn on writes for a profile that ships with writes disabled. It can broaden a write-enabled profile's allowlist, which is why imported policy still requires review.
A model cannot directly read the credential store or own the SSH connection. The provider/agent surface receives model-facing data and fixed tools; the Rust host resolves credentials and owns transport.
A forged or modified aet1 cannot grant entitlement merely because it looks like a token. The app and broker pin token shape, algorithm, issuer, audience, key ID, claims, signature, and time windows. Unknown keys and invalid signatures fail closed; they do not fall back to a weaker account path.
A Clerk session cannot become an app credential merely by being pasted into the desktop. Clerk is verified on the website-side account worker; the app accepts the account-worker grant and later trusts broker-signed aet1 tokens.
Invalid signature math is not implemented from scratch in the Cloudflare services. Clerk RS256 and broker Ed25519 signature operations use the platform's crypto.subtle Web Crypto primitives. The desktop uses the maintained ed25519-dalek verifier. Parsing and claim validation remain application code and must still be tested and reviewed.
Hosted AI does not receive an SSH socket. The broker receives the model request body and forwards it upstream; device commands still execute through the desktop host's governed path.

These are path properties, not claims that a modified binary, compromised OS, stolen signing key, or direct human terminal cannot perform the same underlying device operations.

7. Account and token controls

Clerk session verification pins algorithm, issuer, origin/authorized party, audience, time claims, and a configured public key. Web Crypto performs the signature check. The desktop never embeds Clerk.
adc1 is a high-entropy, generation-bound device credential with an authenticated routing tag. Current and retired secrets are normally stored as hashes; recoverable pending/initial material exists only to make rotation and lost-response replay deterministic and is cleared by lifecycle/revocation rules.
Credential comparisons are designed to avoid status and generation oracles, and refresh operations use durable request IDs so a retry does not advance generations twice.
aet1 is a compact EdDSA JWS. It binds account, app device, credential generation, entitlement, tier/capabilities, display label, plan version, and time limits to the broker signature.
The desktop ships broker public keys rather than fetching a runtime JWKS, preserving offline verification and reducing runtime key-discovery spoofing. Key rotation requires a two-key overlap and an app release.
The hosted broker independently verifies the token and re-reads mutable entitlement projection before spending credits. A bad-signature/unknown-key token never falls through to a legacy credential path.
Known revocation is fail-closed. When the app is fully offline it cannot discover a revocation that occurred after its last contact; the signed offline window therefore remains a bounded residual exposure.

8. Residual risks and honest limits

| Residual risk | Why it remains | Current mitigation / required action | |---|---|---| | Redaction miss | Vendor output is open-ended; pattern-based redaction cannot prove it finds every secret or customer datum | Redact before model/export, re-redact at export, minimize triggered output, expand adversarial tests; treat LLM route as sensitive | | Prompt injection or model error | A device can place instructions in output; the model can still mislead the operator or request permitted reads | Treat device/model text as untrusted; fixed tools; host enforcement; human review; provenance and audit | | Overbroad BYOP | Additive policy can expand the allowed surface on profiles where writes already ship enabled | Immutable floor and block-wins remain; warn and review/test imported policy; do not market BYOP as risk-free | | Approval fatigue/social engineering | A human can approve a harmful but permit-listed change | Diff-first UI, exact statements, target and lockout warnings, no model-controlled approval; training and conservative policy curation | | Vendor semantic drift | Firmware or CLI context can change the meaning of an allowed line | Vendor-specific policy, sequence checks, fresh pre-write capture, live tests, fail closed on unknowns | | Rollback/verify failure | Management loss, crash, concurrency, partial commit, bad baseline, or device limitation can make recovery incomplete | Anchor/timed revert, fenced lease, durable journal, explicit unknown/failed states, manual recovery runbooks | | Unrestricted human terminal | The terminal is intentionally a normal network terminal; human keystrokes are not phase-controlled | Clearly scope security claims to AI-originated governed actions; paste warnings are advisory | | Local host compromise | Malware running as the user can target the app, memory, credential manager, or terminal | OS protections, signing/update security, least privilege, endpoint controls; not eliminated by app architecture | | Account or signing-key compromise | A stolen Clerk/social account, Worker secret, or Ed25519 signing key can authorize devices/tokens | MFA/provider controls, secret rotation, overlap keys, revocation, monitoring, incident runbooks | | Token theft/offline window | A bearer token can be replayed until expiry; an offline client cannot learn a new revocation | One-hour token, account/device binding, mutable server recheck for hosted spend, maximum offline window, keystore storage | | Hosted-provider retention | Broker and LLM necessarily process user-triggered prompts and redacted output; platform logs or provider retention may exist | No application database copy of prompts/configs; our AI providers may retain data under their applicable policies; minimize payloads and keep the privacy notice accurate | | Availability dependence | Account sign-in, refresh, hosted AI, and entitlement checks depend on Clerk/Cloudflare/LLMs/Lemon Squeezy | Typed failures, bounded retries, limited offline behavior; the Service has no uptime SLA and may be interrupted | | Frontend/IPC compromise | Tauri webview or dependency flaws could attempt privileged host calls | Narrow commands, host validation, CSP/supply-chain controls, code signing, continuous review |

9. Security verification priorities

Test aet1 verification for old/new key overlap, unknown key, bad signature, wrong audience, expiry, not-before, and offline-window behavior.
Exercise the full browser handoff → adc1 exchange/refresh → aet1 mint → hosted broker call → revocation path against production-like services.
Run permit-policy, BYOP immutability, escape-floor, sequence-context, governed-write, live verify, and rollback suites on the exact release commit.
Validate installer/code signing, update provenance, Clerk and Lemon webhook secrets, broker signing-key custody/rotation, and incident-revocation runbooks.
Before reusing a technical statement publicly, scope it to the exact tested release, preserve the residual-risk qualifications, and keep it consistent with the EULA, Terms of Service, Privacy Policy, and security page.