Let your ops agent work on a hundred machines without SSH access to any of them.

The question your security team asks

"What can the agent do on the box?" With SSH keys or a brokered session, the honest answer is "whatever its Unix account can do". With bastn, the answer is a list: these actions, with these values, on hosts with these labels.

How it works on a fleet

1. One connector per host. A small binary on each VM dials out to your bastn gateway over mutual TLS. No inbound port, no VPN, no SSH key for the agent. Each host enrols with labels such as web, db or prod.
2. Actions from the tools you already run. systemctl, journalctl, ip, df and your own CLIs become named actions with typed arguments. Read-only Linux diagnostics ship ready to use.
3. A menu per agent. Your triage agent gets status and logs. Your remediation agent also gets restart, on web hosts, held for approval. Restart comes from a reviewed custom spec; the shipped Linux pack is read-only.
4. Labels do the reach. A new host with the web label gets the web actions as soon as its connector enrols. The agent is not reconfigured per host.

What the agent sees

The agent calls the actions in its menu. Anything else is refused before it reaches a host.

triage-agent -> service_status   unit nginx · on web-42     allowed   audited
triage-agent -> read_logs        unit nginx · since 15m     allowed   audited
triage-agent -> restart_service  unit nginx · on web-42     refused   not in this agent's menu

What stays out of reach

• No shell by default. Raw commands are off unless you enable them, and every raw call waits for approval. Commands run as plain arguments, never through a shell.
• Commands run as a dedicated non-root user (run_as). Running commands as root is refused. The connector process must run as root to switch to that user. The published image runs as uid 10001 and does not switch users.
• The host has the last word: a program allowlist, a maximum effect per program and blocked flags, set on the machine.
• A value that does not match its type or pattern (for example eth0; reboot as an interface name) never reaches the host.

When something needs a person

Destructive actions are held for approval by default. New tools can be denied until you review them (new_tools: deny). The approver sees the action, the host and the exact arguments. When no action fits, the agent can submit a script. It runs after review, and approval pins the script's hash.

What you can show your auditor

Every decision goes into a keyed, hash-chained log: which agent, which action, which host, which arguments, what bastn decided. Export it and verify it offline with your key.

Fits next to what you have

Keep your access broker for people and your job runner for scheduled automation. bastn is the path for agents.