DS9.
AI operations

Server access without anyone holding the keys

A jump box holds the SSH credentials; both the agent and the administrator work through an approved API. Linux infrastructure managed from a browser, with no keys on the laptop.

Client
own and client Linux infrastructure
Status
Production · 2026
Outcome
  • The AI agent manages servers without ever seeing an SSH key or a machine address.
  • Every session has an approval, a hard timeout and an audit record.
  • The administrator needs only a browser; no credentials remain on the endpoint.
Stack
Python and FastAPItmuxSQLite WALFernetPAMntfysystemd
trust boundary AI agent holds no keys Administrator approves the session Jump box SSH credentials tmux sessions audit log timeout and revoke Server 1 production Server 2 databases Server N branch sites HTTP API approval SSH
Figure. Credentials never cross the boundary from left to right. Both the agent and the human ask; the jump box executes.

The problem

The moment you give a language model access to servers, you have to answer the question every security auditor asks: what stops a misunderstood instruction from dropping the production database. "The model is careful" is not an answer.

The second problem is practical and concerns people rather than agents. The keys to the whole infrastructure usually live on the administrator's laptop. That laptop travels, joins other people's networks, and occasionally gets lost.

What was built

Both problems have the same solution: credentials belong not to whoever issues the command, but to the intermediary that executes it.

The jump box is the only place where SSH keys and server addresses exist. They are stored encrypted and cannot be retrieved, not even through the API. The agent and the human both get an HTTP interface through which they request a session on a specific machine.

The request does not go straight through. The administrator receives a notification and the session opens only after approval. It runs as a tmux session with a hard time limit, the whole session is written to an audit log, and any session can be terminated and its access revoked immediately.

Opening a session on a production server
agentI need to check the state of the postgresql service on db-prod-01.
gatewayRequest recorded. Target: db-prod-01. Scope: read service state. Awaiting approval.
approvalAllow a 10 minute session? Notification sent to the administrator.
resultSession opened 14:22, closed 14:24. Audit record 4471.

For humans, the same infrastructure is available as a web terminal. The administrator signs in with a system username and password and works directly in the browser, including from a phone. No key is left on the device, because none was ever there.

Why this is not just another web shell

The difference shows up when something goes wrong. With a conventional SSH key on a laptop, compromising the device means compromising the infrastructure, and the only defence is rotating every key. Here the response is one button: sessions close, access is revoked, and the audit log shows exactly what was executed before it happened.

This design moves risk rather than removing it. The jump box becomes the most valuable machine on the network and must be treated accordingly: dedicated hardware, a minimum of other services, separate backups and regular audit review. Deploying it on a server that also runs something else gives away most of the benefit.

Result

The gateway runs in production as an unprivileged service and manages real Linux servers. The web terminal over the same infrastructure allows administration from anywhere there is a browser and a login — and nothing more.