Let an AI agent reach your server without giving it the SSH key

Your agent has a reviewed change and the next step is a server. The quick route is to paste a private key into the conversation or leave one on the agent's machine. Either way, the key now lives in a transcript or a file you no longer track, and possibly in a model provider's context.

There is a better split, and most of it works with any tooling.

Write down the task before granting anything

"Give the agent server access" does not say enough to approve or refuse. A useful request names the work. This one is an illustrative example:

Task: deploy the reviewed build to staging
Destination: the project's staging host
Account: a deploy account restricted on that host
Expected result: the new build answers on the staging address
Out of scope: production

The destination, the account and the procedure belong in your project documentation. The next conversation needs them too. The private key does not belong there.

Separate three permissions

People tend to bundle these together:

1. Read the project: know which servers exist, what they are for and how to deploy.
2. Run work: execute commands in an allowed environment.
3. Use one credential: authenticate to one service with one key.

Once they are separate, an agent can prepare a precise request before it holds any operational access, and permission to execute does not unlock every key you own.

A document must never count as one of these permissions. An agent reading that a server exists has learned something. It has not been authorized to connect.

Run the work where the key already is

The key stays out of the conversation if the agent never needs to possess it. Whatever tool you use, the pattern is the same: the agent asks for a command to run on a named destination, and a separate component holds the key, opens the connection and returns the output.

For a small setup, that component can be a CI job or a deploy script behind an approval. What matters is that the agent names the destination while something else holds the credential.

Size the account, not just the secret

Hiding a key does not limit what it can do. If the key opens a root account, an approved command can still do anything root can do. So:

• use a deploy account that can only do the deployment;
• give each project its own key where you can;
• make grants expire, and limit them to the task at hand.

Filtering secrets out of command output helps with accidents. It will not stop a command written to send a secret elsewhere, so treat it as a safety net rather than a boundary.

Record what actually happened

"Done" is a poor handoff. The next collaborator needs the outcome, the evidence and what remains open:

The reviewed build was deployed to staging. The health check passed. Mobile interaction still needs review. Production was not changed.

An approved request shows that an action was allowed. It does not show that the action worked.

How Fileaify supports this

In Fileaify, the project documents its destinations in a hosts table, where each row references a key in the vault by name. To connect, the agent needs two grants that a person approves: executor.run for the project and secrets.use for that key.

The agent then asks for a command on a named host. The executor, a small server dedicated to your account, uses the key on its side. The key does not reach the agent's machine or conversation, and known secret values are redacted from the output. The same limits apply: a grant covers commands within its scope, and each of those commands is not reviewed separately.

The executor is available from the Solo plan. The demo lets you try the request and approval flow on a prepared project, without your own keys. The exact rules are in the executor reference.