Built for the day it is wrong
Giving an AI access to production is a real risk, and pretending otherwise would be the wrong pitch. So the design starts from the assumption that it will occasionally be wrong, and makes that survivable. Below is what is enforced, and what is not.
What is guaranteed, and what is best effort
Most security pages blur these together. Yours is easier to assess if we do not.
These hold by design
- Private key material is never sent to the model. Enforced by file type (.pem, .key, .ppk, .pfx, .p12, .jks, id_rsa and friends) and by detecting the key block itself in any output. This holds under both policies and on every path, including running your own scripts.
- The agent cannot compose a command. It supplies parameters into command shapes we defined. Shell metacharacters are rejected, so there is no pipe, no semicolon, no substitution, and no way to turn a read into something else.
- Protected paths are refused, wherever they are. Directories like .ssh, .aws, .gnupg, .kube, .docker, .azure and .gcloud, and files like .netrc, .pgpass, .git-credentials, .my.cnf and service-account.json, are denied by name anywhere on the filesystem, not just under paths we could list.
- Nothing changes without a person approving it. Reads run freely. Every write, restart, install, permission change or delete stops, shows what it is about to do, and waits.
- Changes are reversible. Files are snapshotted before they are written, kept on your own machine so a rollback survives the server. Folders are archived on the server itself before they are removed. Config is validated before it is applied where the tool supports it.
- Every action is recorded. What ran, who approved it, and what came back, written to a transcript you can read.
These have known limits
- Redaction of secret values is pattern-based. It detects key names containing PASSWORD, SECRET, TOKEN, KEY, SALT, AUTH, CREDENTIAL and similar, plus credentials embedded in URLs, AWS access keys, JWTs and bearer tokens. A value with an unusual name and no recognisable shape can get through. Treat it as a second net, not the first one.
- The default policy lets the agent see config values. Under the default, config and environment values are visible to the model so it can help you edit and deploy, and it warns you when it sees a secret-looking key. Strict mode masks those values as well. Which one applies is set centrally for your account, not per conversation.
- A person can always paste a secret into the chat. Anything typed into the conversation goes with it. No tool can prevent that, and we would rather say so than imply otherwise.
The short version: do not rely on redaction as your only protection against a secret reaching a model. Scope the account it connects with, and treat masking as the second net.
Scope it before you trust it
The strongest control is the least clever one: the agent only reaches what the SSH user you gave it can reach, and it is refused before that if a path is protected.
If you hand it an SSH user with broad rights, it inherits them. Scope it the way you would scope a new team member on their first week.
- It connects as an ordinary SSH user that you create and can revoke like any other
- Per-server restricted paths, set by you, are denied by prefix
- A built-in deny list refuses credential directories and files by name, anywhere on disk
- Path traversal is rejected, paths must be absolute, and reads stay inside allowed roots
- Elevated access is off until you turn it on for a specific server
It supplies parameters, not commands
This is the difference between a tool with server access and an AI with a shell. The model never writes the command. It chooses from shapes we defined and fills in the blanks, and those blanks are validated before anything runs.
A script you wrote and approved runs as written. The guard is on what the model can invoke, not on what your own scripts choose to do.
- Command shapes are fixed in the product; the model provides arguments only
- Shell metacharacters and sequences are rejected outright, so nothing can be chained or substituted
- Arguments are validated for type, length and location before execution
- Discovery sweeps run against a tier-limited allowlist, and their output is always fully redacted
- Running your own scripts is explicit and gated, not a general shell
Approval before anything changes
Reads are free and instant, because reading cannot hurt you. Everything else stops for a person, every time.
A person still has to read what they are approving. The gate protects against surprise, not against approving on autopilot.
- Writes, restarts, installs, deletes and permission changes are all gated
- You are told what will change, on which server, and shown the command or a red and green diff
- Approval is per action, not a session-wide switch that gets left on
- Declining is a first-class outcome: it stops and tells you what it would have done
Mistakes stay recoverable
The design assumes something will eventually be wrong. What matters is whether it can be undone in a minute.
Worth knowing where each copy lives: file snapshots sit on the workstation of whoever made the change, which is what makes them survive a lost server, and also means an edited file has a copy outside the server. Folder archives never leave the server. And some things cannot be undone by anyone, so reversibility has physical limits.
- Every file is snapshotted before it is written, and the snapshot is kept on your own machine rather than the server, so a rollback still works if the server copy is gone. The last 30 versions of each file are held
- A folder is archived on its own server, in place, before it is removed, so restoring it does not depend on copying anything back across the network
- Script edits keep a version history you can revert to
- Configuration is validated before it is applied where the tool allows, for example nginx -t before a reload
- Database access is read-only, with a guard that refuses anything that writes
Redaction, and what it does not cover
Everything on its way to the model passes through a single gate rather than each tool deciding for itself. That gate is strong on key material and best-effort on everything else, and it is worth knowing which is which.
Pattern matching can miss an unusually named value. That is why this is layer five and not layer one: the system is designed so that a miss here is not the only thing standing between a secret and the model.
- Private key material is masked unconditionally, by file type and by detecting the key block in any output
- Secret-looking keys, URL credentials, AWS access keys, JWTs and bearer tokens are matched by pattern
- Discovery sweeps are always fully redacted, because their output is written to disk
- The agent is blocked from writing a masked placeholder back into a real file
- Database credentials are encrypted at rest and are never put in a prompt
- Strict mode masks config and environment values as well, and is set for the whole account
A record you can read afterwards
Not for blame. For the two questions that actually come up: what changed this afternoon, and can we undo it.
The log lives with the app rather than in a SIEM. If you need it shipped somewhere central, that is an Enterprise conversation.
- Every action, the approval, and the result are written to a transcript
- Discovery keeps its own audit of what was run and what was returned
- Teams on a shared plan see the same log across the team
- Enough detail to reconstruct an incident without asking anyone
How we would deploy it, if it were our estate
Six things, none of which take long. The first one matters more than every setting inside the product, because your operating system enforces it rather than we do.
-
Create a dedicated SSH user for the agent
Not your personal login and not root. A separate user makes the audit trail meaningful, keeps the blast radius visible, and means revoking access is one line in authorized_keys rather than a rotation of your own key.
-
Give it its own key, with a passphrase
A key used by one tool can be rotated without disturbing anything else. If that key ever needs to be replaced, nothing you use daily has to change.
-
Set restricted paths per server
The built-in deny list covers the usual credential locations. Add anything specific to your estate: customer data directories, backup mounts, another tenant's application root.
-
Leave elevated access off, then grant it narrowly
Most work does not need it. When something does, turn it on for that server, and prefer a wrapper script with a fixed set of operations over general privileged access.
-
Start on staging, or on the least important server you own
Not because it is dangerous, but because the first hour is when you learn what it shows you before it acts, and that is cheaper to learn somewhere forgiving.
-
Decide your redaction policy deliberately
The default lets the agent see config values so it can help edit them. If your environment files hold something you would not want in a model prompt, switch the account to strict and accept that some editing help gets narrower.
What leaves your machine
The short version, without the legal wrapper.
Sent to the model
- Your question, and the conversation context
- Command output after redaction, so the model can reason about it
- File contents you asked it to read or change, subject to the policy above
- Config and environment values, unless the account is set to strict
- Usage metering: token counts and the model used, for billing
Never sent
- Private key material, under every policy and on every path
- SSH keys and database credentials, which stay encrypted on your machine
- Anything inside a protected directory or a restricted path
- Any file you never asked it to open
- Anything on a server you have not registered
One thing worth stating separately, because it is not a model question: when a file is edited, a snapshot of it is written to the machine of the person making the change, so a rollback works even if the server copy is lost. That means an edited file also exists on that workstation. Deleted folders are archived on their own server instead, and never travel.
Enterprise customers can self-host the proxy, in which case the conversation goes from your network straight to the model provider without passing through ours.
What review boards ask
Can the AI see our passwords and API keys?
What stops it running a destructive command?
Do you store our command output?
Can a developer use it to get around our access controls?
What is the single most important thing we should configure?
Will you answer our security questionnaire?
Send us the hard questions
If your security review needs something specific, ask. We would rather answer it now, in writing, than have it surface after you have bought.