How to audit and record what an AI agent does on your servers

The moment you let an AI agent touch a real server, a new question appears that never mattered when it was just you at the keyboard: what did it actually do? Not what it says it did — agents narrate their work, and the narration is often tidy fiction, skipping the command that failed, the file it read "just to check," the thing it tried before the thing that worked. When you ask a human colleague "what did you run on prod last night?" you're trusting a memory. When you ask an agent, you're trusting a language model's account of a language model's actions. Neither is an audit trail. This post is about building one.

Why the agent's own report doesn't count

Three reasons, and they compound:

• It's produced by the thing being audited. A record the actor writes about itself is a statement, not evidence. If the agent is confused — or steered by a poisoned log line or filename it read along the way — its report is confused or steered too.
• It's lossy on purpose. Models summarize. The command that returned an error, the exploratory cat of a config, the curl to an address you didn't expect — exactly the lines an incident review cares about — are the ones a summary drops as noise.
• It isn't attributable later. "The agent cleaned up disk space" is not something you can hand an auditor, diff against a change ticket, or replay six months on.

The fix is the same one that has always separated a real audit trail from a story: make the record outside the actor, capture the raw session, and attach identity and time to it.

What a real trail needs

Borrowing the checklist from auditing sessions on a bastion, an agent trail has to answer who, when, from where, what, and can I trust this — with one addition unique to agents:

• Every command captured as it ran — not a summary, the actual session output, replayable with its original timing.
• The agent distinguished from you. The single most important field. A record that can't tell "the agent ran this" from "I ran this" forces you to reconstruct at 2 a.m. what should have been a filter.
• Connection metadata alongside — which host, when, from which device and IP.
• Output, never keystrokes. More on this below — it's the trap that turns an audit trail into a liability.
• A record the agent can't quietly edit. If the actor can rewrite its own history, you're back to trusting the story.

The keystroke trap — sharper for agents

A terminal session has two streams and they are not symmetric. Output holds every command that ran (the shell echoes it) plus everything those commands printed — the complete forensic record. Input adds exactly one thing output doesn't: the characters deliberately not echoed — sudo passwords, passphrases, a token pasted into a prompt.

Record input and you haven't built an audit trail, you've built a keylogger aimed at your own infrastructure. With agents it's worse: agent sessions are the ones you're most likely to record by default and least likely to be watching keystroke-by-keystroke, so a capture-everything setting quietly becomes a growing archive of secrets nobody decided to collect. The rule holds in every layer: record output, never input.

Server-side, client-side, or both

You can record where the session lands (on the server, with tlog or auditd) or where it originates (in the client). For agents specifically, the client side isn't just a nice complement — it's the only layer that can capture the fact that mattered most: who was driving. A server-side recorder sees a session on db-01; it cannot see that a model opened it via MCP rather than a person via ssh. That distinction has to be stamped in at the source, by the thing that brokered the connection.

So the strong setup is: client-side recording that marks agent commands, plus server-side recording where you need the "everyone, no exceptions, whatever client they used" guarantee. The two answer different questions and corroborate each other in a review.

Doing it with Termalin

Termalin is the client-side layer, and because its MCP server is also the thing brokering the agent's access, it can stamp the record at the source:

• Sessions are recorded output-only by design. Keystrokes are never captured — there's no setting to turn that into a keylogger. Turn recording on in Settings → Terminal or per host on the host form, and set a retention window (7, 30, 90, 365 days, or forever) so old recordings prune themselves instead of piling up as liability.
• Agent commands are marked. Each command an agent issues gets its own green marker on the replay timeline (your commands and system events are amber), and the same distinction is written to the audit log. "Show me only what the agent did" is a filter, not a reconstruction.
• The audit log carries the metadata. Every sign-in, host connection, file operation and agent command, with where (IP · country) and which device — the who/when/from-where an auditor asks for, correlated with the session instead of scattered across log files with drifting clocks.
• You can watch it live. The watch grid mirrors every open session as a tile, and the ones an agent is driving glow. Live oversight doesn't lower the odds of a bad instruction landing — it lowers dwell time, so a steered agent is caught in minutes, not discovered in a postmortem.
• Recordings the agent can't rewrite. On paid plans they sync end-to-end encrypted — the server stores ciphertext it can't replay, and you replay from the web cabinet anywhere. The record survives even if the box the agent touched is rebuilt.

The honest limits

Worth stating plainly, because a trail you over-trust is its own risk:

• A recording proves what ran, not what leaked. If your policy lets the agent cat a file, cat .env returns your secrets into its context, and the recording faithfully shows it happening — after the fact. Auditing tells you that it happened fast; it doesn't prevent it. Pair recording with a tight per-host command policy and with keeping secrets off disk.
• Client-side covers the sessions that go through the client. It can't testify about a session someone opened another way — that's what the server-side layer is for.
• "Marked as the agent" is only as trustworthy as the broker. The custodian doing the marking is now a thing to protect; concentrating that trust in one hardened place is the right trade, but it is a trade.

None of these are reasons to skip the trail — they're the difference between having an audit story and believing a marketing one. The same setup runs in CI, where every hosted run is logged against the API key that made it.

---

Termalin is a free, cross-platform SSH client with output-only session recording, an agent-tagged audit log and a live watch grid — download it, or read the security model.