Where Your SSH Keys Actually Live: The SysNav Architecture

"An AI that can run commands on my servers" is a sentence that should make any operator nervous. The first question isn't "is it smart?" — it's "where do my credentials go, and what can reach them?"

Here is the honest, complete answer for SysNav. No hand-waving about "enterprise-grade security." Just the data flow.

The split: the cloud reasons, your device executes

SysNav is two programs, and the boundary between them is the whole security story.

  Your Mac (SysNav desktop)            SysNav cloud service
  ─────────────────────────            ────────────────────
  • SSH private keys                   • The LLM reasoning loop
  • known_hosts, ssh-agent             • Ask/Agent orchestration
  • env vars, .pem files               • The command-safety gate
  • Executes the command  ──────┐
                                 │
        redacted context  ◀──────┘ (what the model is allowed to see)
                                 ┌──────────────────────────────┐
        command proposal  ◀──────┤  "run: systemctl status nginx"│
                                 └──────────────────────────────┘
        you approve  ──────────▶ executed locally, on your machine
        command output  ──────▶  redacted, then sent back to reason on

The cloud service is where the model thinks. It decides what should happen next and proposes a command. But it has no SSH client. It cannot open a connection to your hosts. It never receives your private keys. That isn't a policy we promise to honor — there is no code path in the service that dials out to your infrastructure.

The desktop app is the only thing that touches your servers. It holds your keys, opens the SSH connection, runs the approved command, and sends a redacted result back up for the model to reason about.

What "redacted and ephemeral" actually means

When command output flows back to the cloud, it is the material the model needs to answer your question — log lines, process lists, status output. It is processed in memory to produce the next step and is not retained as a SysNav training dataset. We are deliberately not saying "we delete everything instantly" or "zero data ever leaves," because those are the kinds of absolute claims that turn out to be false under audit. What we can say precisely: your keys never transit the boundary, and the context the model sees is the operational text, not your secret material.

The threat model, stated plainly

Security is only meaningful relative to a threat model. Here is ours.

If the SysNav cloud service were fully compromised, an attacker would have:

• The reasoning loop and your conversation context.
• The redacted command output you've run during a session.

They would not have:

• Your SSH private keys (they never left your Mac).
• The ability to run a command on your servers without your approval (every Agent-mode action is gated behind an explicit approve step on your device).

If your Mac is compromised, all bets are off — but that is true of every terminal you've ever used. SysNav doesn't widen that surface; your keys were already there.

Why we built it this way instead of the easy way

The easy way is a cloud agent with your keys in a vault, executing autonomously. It demos beautifully. It also means a breach of the vendor is a breach of every customer's fleet, and "the AI did something I didn't approve" becomes a real incident class.

We took the harder split — keys local, execution local, approval local — because it's the only design where the worst case is bounded. A compromised SysNav can leak what you showed it. It cannot own your servers.

That's the trade. Read the prompt-injection write-up for what happens when a malicious log line tries to turn the agent against you — the same boundary is what contains it.