Cloak_SSH & Passport: How six tools we built provide you with backups, safety, and security for your keys.
Before Cowork/Work Mode existed
For most of the last four years, using a chatbot against your own infrastructure meant one of three average options. You pasted file contents into the chat by hand, clogging up the context window.
You built a bespoke plugin or function-calling backend just to shell out to your VPS or PC. Or you gave the model standing, unscoped credentials, and hoped that it didn't go rogue, deleting files or rewriting sensitive information without a backup made.
Cowork mode and equivalents (OpenAI’s file/work tools, Claude’s desktop file access) solved the local half of this problem: an agent can now read and write files in a folder you point it at without a custom integration.
They are useful tools but don’t fully solve all the remote issues. The moment your actual work lives on a VPS, a home server, or a machine on a private network, desktop file access stops being relevant. You’re back to opening a raw, permanent SSH tunnel and trusting the model with it indefinitely without backups.
The tool that we built, Cloak, an ethical, transparent SSH tool, exists to close that specific gap: remote command execution and remote file access, with the credential handling and approval mechanics that standing SSH access doesn’t give you by default.
And you can use Cloak in conjunction with Co-Work to fill in any missing gaps those systems can’t do.
What Cloak actually is
Cloak is not one tool. It’s a hybrid, multiple tools bolted together on purpose working in synergy:
An SSH execution layer (cloak_ssh_exec, cloak_ssh_approve, cloak_ssh_plan, cloak_ssh_backup, cloak_ssh_rollback) that runs commands on a remote host, classifies each command by risk before it runs, and gates anything destructive behind an explicit approval step.
An AES-256 encrypted credential vault (cloak_passport) that stores SSH keys, API tokens, and secrets separately from the execution layer, releases them only on request, and is designed around the assumption that keys should never sit at rest on the machine that's being administered.
What’s specific to Cloak is that both tools are wired together: the execution layer calls the vault mid-command, uses the credential for exactly one operation, and the credential never persists past that operation. That’s the actual design decision we built after 6 months of trial, error, and refining, and we eat our own dog food daily and know that it works perfectly.
And the ideas were not borrowed from other devs' code online, they evolved from resolving the challenges we were facing daily using LLMs. And it didn’t take a floor of overpaid AI researchers in Silicon Valley or oodles of VC money either.
Cloak Tool Diagram
Security, the standing-key problem
The default way people give an AI agent SSH access is to drop a private key in ~/.ssh/ on the box the agent runs from, or worse, on the target box for convenience, and leave it there. That key is now a permanent artifact. If the agent's environment is ever compromised, or if a session log leaks, or if the sandbox itself gets popped, that key is sitting there, valid, until someone remembers to rotate it.
How often does your team rotate your VPS keys? Not very often in most cases, unless you are slightly paranoid about security or just very thorough.
Cloak’s vault pattern inverts this. The pattern actually used in production, verbatim from how it works in practice:
- cloak_passport({ action: "get", key: "some-host-hop" }) → returns keyText
- cloak_ssh_exec writes that key to a scratch file, uses it for exactly one SSH connection, then deletes (or shreds) the scratch file in the same command block — never as a separate step.
- The key never touches disk outside that single command's lifetime. The “same command block, not a separate step” detail matters more than it sounds like it should. If the cleanup were a second, independent call, a crash, a timeout, or an interrupted session between step 2 and the cleanup would leave the key on disk. Bundling write-use-shred into one atomic shell invocation means there’s no window where an interruption leaves a credential behind.
The corollary is that a compromised target host learns nothing permanent. In an actual documented case, a private key that had been resident on a VPS was pulled and re-homed into the vault specifically because a standing key on the box being administered is a pivot risk if that box is ever compromise, an attacker who gets a shell on the target doesn’t get a key that also opens other systems, because there isn’t one to find.
We can show you the logs below, and the majority of attacks are now agentic bots. It's a new world, and it only will become more nefarious as trillions of bots swarm the networks and ping your servers for remote access to open ports. And these are small numbers; imagine a large corporation or a hot target that stores customers' credentials.
Combined VPS logs: roughly 1,640 unique attacking IPs blocked and 41,934 malicious requests/attempts logged across both jails, over the last 67 days
We do not store any customer info or data as per our PET policies, so they are pointless attacks, not that the bots would know that, as they are hunting everything on a 24/7 cycle via zombie hosts or self-replicating bots making bots.
In November 2025 a campaign (tracked as GTG-1002) demonstrated autonomous AI agents coordinating attacks across 30 organizations simultaneously, with 80–90% of the operation running without human input, the agents shared intelligence in real time and adapted their approach as defenses responded.
That’s qualitatively different from a static botnet replaying the same script: it’s an adversary that notices what’s blocking it and route around that specific thing, live.
OpenClaw, an open-source AI agent framework that launched in January 2026, had thousands of instances left exposed by default configs and got hijacked into a botnet within weeks, meaning some of the “swarm” doing this kind of attack now is itself made of compromised agentic tooling, not traditional malware.
Interesting article, not affiliated: https://vps.us/blog/state-of-botnets/
Over half of all internet traffic is now automated. Bad bots alone account for 37% of it, up from 32% the year before. In 2025, the global internet absorbed 47.1 million DDoS attacks — roughly 1.5 every second — and the largest single strike peaked at 31.4 Tbps, lasting just 35 seconds.
Back to the vault’s algorithm
The vault itself is AES-256 at rest, it’s a symmetric cipher, which means the only known quantum attack against it, Grover’s algorithm which gives a quadratic speedup, not the exponential break that Shor’s algorithm delivers against RSA or elliptic-curve keys.
Shor’s algorithm (1994) is a quantum algorithm that factors large integers and solves discrete logarithms in polynomial time — the exact math that RSA, Diffie-Hellman, and elliptic-curve cryptography depend on being hard. A sufficiently large quantum computer running Shor’s doesn’t slow those systems down, it breaks them outright: what would take a classical computer longer than the age of the universe drops to hours or less. This is why RSA and ECC are considered “quantum-vulnerable” and why the industry is actively migrating to post-quantum algorithms for anything asymmetric.
Grover’s algorithm (1996) is a different kind of quantum algorithm — it speeds up unstructured search, which is what brute-forcing a symmetric key like AES actually is. But the speedup is quadratic, not exponential: searching a keyspace of size N drops from N operations to roughly √N. Applied to AES-256, that means a quantum computer doesn’t reduce security to nothing, it roughly halves the exponent — 256 bits of security becomes the equivalent of about 128 bits. That’s still computationally out of reach. There is no known quantum algorithm, Grover’s included, that breaks AES the way Shor’s breaks RSA.
A quantum computer running Grover’s against a 256-bit key reduces the effective search space to roughly 128 bits of security, not zero. Brute-forcing a 128-bit keyspace is still on the order of 2¹²⁸ operations — a number large enough that no computer built from ordinary matter, quantum or classical, gets there before the heat death of relevant timescales makes the question moot.
That’s why AES-256 specifically, not AES-128, is the standard choice for anything that needs to stay secure against an adversary who might have a quantum computer someday: it’s sized with that headroom built in, not bolted on after the fact. But none of that is the actual point.
The cipher was never the weak link in a credential-handling system; the weak link is always when and where the plaintext exists on your servers and PCs.
A perfectly unbreakable vault still fails if the decrypted key sits on disk for the ten minutes after it’s fetched. The real security property Cloak is built around isn’t the strength of AES-256, which is already more than sufficient—it's minimizing the window in which there’s a secret to attack at all.
Human-in-the-loop—the most important step which keeps you in control
Every command that goes through cloak_ssh_exec gets classified before it runs. Read-only operations (cat, ls, grep, status checks) execute immediately. Anything that writes to disk, installs a package, modifies a config, or kills a process comes back with:
{
"tier": "write",
"executed": false,
"requires_approval": true,
"approval_token": "",
"preview": { "command": "...", "classification": "write", "warning": "modifies files or packages" }
}
Nothing runs. The command sits in a pending state, and the operator (human or the calling agent, but ultimately visible to the human) has to call cloak_ssh_approve with that exact token before the shell instruction executes. This is the mechanical difference between "the AI has SSH access" and "the AI can propose SSH commands that a human confirms." Those are not the same risk category, and conflating them is where most agent-SSH setups get uncomfortable to reason about.
A few things about this that are easy to get wrong if you build it yourself:
The token is per-command, not per-session. Approving one write doesn’t grant a standing window where subsequent writes auto-execute. Every write, every time, gets its own gate. This is more friction than a session-level approval, and that’s the point — it means a runaway loop can’t silently execute forty destructive commands because the first one got a thumbs-up.
Read operations don’t ask. If everything required approval, the approval prompt would become background noise the operator stops reading — the exact failure mode that makes UAC dialogs and cookie banners useless. Only commands that can change state interrupt you.
Every approved write comes back with a live health check, not just the command’s own output. In practice this means a pm2 list and a targeted service check ride along with the response automatically, so "did this break anything" is answered in the same round-trip as "did this succeed," rather than requiring a separate follow-up query.
The plan/backup/rollback trio extends this same philosophy to sequences instead of single commands: cloak_ssh_plan lets a multi-step change get previewed as a whole before any of it runs, cloak_ssh_backup snapshots the state that's about to be touched, and cloak_ssh_rollback exists specifically so that "approve" is never a one-way door. You can say yes to a change and still have a documented path back out of it if the yes was wrong.
Accuracy: grounding calls instead of guessing
The third reason is about being correct, a model operating on a remote system without live command access is working from whatever it was told or whatever it remembers from its training—which, for a specific VPS’s actual pm2 process list, actual fail2ban ban count, or actual npm audit output, is nothing. It has no choice but to guess, extrapolate from generic patterns, or hedge everything in qualifiers.
Live SSH execution replaces every one of those guesses with a queryable fact. “Is the server under attack” stops being a question answered from general knowledge about what attacks usually look like, and becomes a question answered by actually running fail2ban-client status, actually grepping auth.log, actually checking ss -tlnp for what's listening. The difference isn't subtle — it's the difference between a plausible-sounding answer and a verified one.
This compounds when the model is also asked to act, not just report. Patching a dependency, restarting a service, editing a config file — every one of these is either right or wrong in a way that’s checkable immediately, in the same session, against the live system.
Backup-before-write and health-check-after-write aren’t bureaucracy for its own sake; they’re what makes it possible to trust an “I fixed it” claim instead of taking it on faith. An agent that can’t check its own work is an agent whose output you have to independently verify anyway, which erases most of the time savings of using it at all.
Why these six, specifically work in unison
Stripped to the tools that actually get reached for on a normal remote-infrastructure session, the set is small on purpose:
cloak_ssh_exec Runs a classified command on a remote host over SSH The execution primitive everything else wraps cloak_ssh_approve Confirms a pending write-tier command by token The HITL gate — without it, exec would need to auto-run writes.
cloak_passport AES-256 vault: get/store/list credentials on demand Removes the standing-key requirement entirely.
cloak_ssh_plan Previews a multi-step change before any step executes Lets a human evaluate a sequence, not just isolated commands.
cloak_ssh_backup Snapshots state before a risky change Makes "undo" possible instead of theoretical.
cloak_ssh_rollback Restores from a cloak_ssh_backup snapshot Closes the loop — approval was never irreversible.
Every other Cloak tool — log tailing, file patching, identity management, fetch/render for web content — is either a convenience wrapper around this core loop or solves an adjacent problem (browser automation, content fetching via cloak_fetch) that doesn’t touch the security model at all.
These six are the ones where removing any single one changes what you’re willing to let an agent do unsupervised, which is the actual test for “indispensable” versus “nice to have.”
Their is always a tradeoff
Per-command approval is real friction for users; a 20-step remediation task means 20 approval round-trips, not one. The vault’s fetch-use-shred pattern adds latency to every single SSH call compared to a resident key (documented at roughly half a second per hop, which is negligible for interactive use but adds up across a scripted batch). And backups before every write cost disk space and time that a “just run it” approach wouldn’t. but also guarantees no issues with failed calls, deletions, or rewrites by an LLM hallucinating.
In the end, when the work is completed, you delete the backups created or store them in a folder for safe rollbacks if needed. Better to have them than need them!
The trade being made is acceptable: slower and more interruptive, in exchange for no standing credentials, no silent destructive actions, and no unverified claims of success.
For infrastructure you actually depend on, that’s the correct trade. For a disposable sandbox you’re going to nuke in twenty minutes anyway, it’s overkill, and that’s fine, because Cloak isn’t trying to be the right tool for that case. It is the tool for when you need HITL and are performing detailed work that needs stepped attention and approvals, so you don't nuke your database and then cry on social media posts that an LLM has to say sorry and can’t recover your files as it didn't make a backup for you.
VEKTOR Memory builds local-first, privacy-preserving persistent memory infrastructure for AI agents. Full technical documentation and changelog at vektormemory.com/docs.
Human In The Loop
Security
Ssh
AI Agent
Top comments (0)