A command log tells you what ran. An audit has to answer who, why, and with whose approval—for humans and agents alike.
Here's a log line from a production server:
2026-05-22T03:14:21Z host=web-prod-04 user=svc-deploy cmd="systemctl reload nginx" exit=0
It looks like proof. It tells you a command ran, on a box, at a time, and succeeded. Now try to answer the question that matters the moment something looks off: why did nginx get reloaded, under whose approval, as part of what task—and was svc-deploy a person or an agent? The line can't say. Multiply it by a few thousand and you don't have forensics; you have noise that happens to be timestamped.
That's a log. It is not an audit. This series has been about keeping AI agents from widening your attack surface (post 1) and governing what they execute (post 2). This is the question you get after something happens: can you prove what happened.
Is a command log the same thing as an audit?
TL;DR: No. A log tells you what ran. An audit has to answer who, when, what, why, with whose approval, and for what purpose—for humans and agents alike.
When an agent does something you didn't expect, "what command ran" is the one thing you already have. An audit has to answer six things: who acted (a person or an agent, with an authenticated identity), when (and inside what session window), what (the command, the paths it touched, the result), why (the declared purpose it was part of), with whose approval, and for what purpose (the business context that makes it legitimate). A command log answers the what, and almost nothing around it. The rest you reconstruct by hand, under deadline, stitching together shell history, ticket links, and someone's memory of who said yes.
That reconstruction was already painful for humans. With agents it breaks. Most organizations can't even see their agents yet—82% report unknown AI agents in their environment—and at RSAC 2026, 63% of teams said they couldn't enforce what an agent is allowed to do. You can't audit after the fact what you never captured in the first place.
What would it take for the audit to answer those questions?
TL;DR: Capture the context as a field at the moment of the action, not as a guess afterward—and put humans and agents on one timeline.
Command logs can't answer those questions because they record the what and drop everything around it. Alpacon's audit works the other way: the context is native to every action, because every action already happened inside a governed session that declared it.
A CISO asking "what happened on web-prod-04 yesterday?" gets a single timeline—not one for humans, one for CI, and one for agents. Every action belongs to a Work Session, and the session carries a required purpose declared up front, the scope it was granted, the approval that activated it, and the risk each command scored. Every entry names the actor and the exact credential behind it—a user, an API token, or a service token bound to an application—so "who" resolves to an authenticated identity, whether that identity is a person or an agent. None of that is parsed out of free-text logs after the fact; it's recorded as structured fields at execution time.
Here's the opening log line again, as an Alpacon record:
2026-05-22T03:14:21Z host=web-prod-04 user=svc-deploy cmd="systemctl reload nginx" exit=0A command ran, on a box, at a time. Not who, why, or with whose approval.
The log gave you the what. Every other line was a field captured when the action ran, not a reconstruction after it.
This is the part that's shipped and load-bearing. The forensic questions are answerable because the answers were captured when the action ran, not reconstructed when someone comes asking—whether that's your own incident review or an outside auditor.
Why does an audit have to be append-only?
TL;DR: An audit you can quietly edit proves nothing. Alpacon exposes the trail through a read-only API—no edit path through the product—and records only age out on a retention schedule, not by editing. Making the store itself cryptographically tamper-evident is the next step.
An audit you can edit is an audit you can't trust. So Alpacon exposes the trail through a read-only API: there's no path to rewrite a record through the product, and records only age out on a retention schedule you set—deletion on a clock, not editing. Today that's enforced at the API; hash-chaining each record so any tampering is detectable at the storage layer is the next step on the roadmap. And the trail lives in a search index, so it's queryable, not a flat file you grep under pressure.
Alpacon isn't trying to be your SIEM. It captures the privileged-access slice—who did what on your infrastructure, with what approval, for what purpose—and keeps it query-ready.
Can you just ask the audit what happened?
TL;DR: Because the context is already structured, the record is queryable today—programmatically over MCP, and in plain English. Alpacon's audit view has an "Ask AI" box: ask "which sessions were high-risk" or "which agent sessions ran sudo" and get an answer over your session history, not a week of log spelunking.
Here's what native context unlocks. Because every action already carries who, when, what, why, with whose approval, and for what purpose, the audit isn't a pile of lines to grep—it's structured data you can query. Today that query is programmatic: an agent or a tool reads the activity trail over MCP and gets back structured, attributed, read-only records.
You can also just ask. Alpacon ships an "Ask AI" box on the audit view: type "which sessions were high-risk this week" or "which agent sessions ran sudo," and it answers over your privileged-session history—semantic retrieval plus an LLM, workspace-scoped, live today. To be precise about the edges, it's an LLM answer over your session records, not a structured query that joins every approval row. The same records are also the kind of record-keeping regulators increasingly mandate—though auto-generating framework-mapped SOC 2 or ISO evidence from them is on the roadmap. Either way, asking the audit what happened isn't a someday demo anymore—it's how you chase down what an agent did without grepping logs for a week.
Three agent sessions ran sudo in the last 7 days. Two were auto-approved as low-risk; one was routed to a human and rejected when the command diverged from the session's stated purpose.
An LLM answer over your session records, workspace-scoped—not a structured join of every approval row.
The point is that this isn't a bolt-on analytics product. It falls out of recording the right things, in the right shape, the first time.
What does this change the next time an agent goes wrong?
TL;DR: The record stops being a scramble you assemble after the fact and becomes a byproduct of how access already works—there the moment you need to answer for what an agent did.
That's the whole series in one line. Post 1 kept the surface flat when you add an agent. Post 2 governed what the agent does once it's in—scope, intent, a human on the ambiguous slice. This post is what makes both provable: an audit that answers who, why, and with whose approval, for people and agents on one timeline, captured at execution time.
Whether the one asking is your incident reviewer or your auditor, the problem is the same—and we're going through our own SOC 2 Type 2 right now, so I'll say the quiet part out loud: it's miserable because the context is reconstructed after the fact, always under deadline. Capture it when the action runs, and the answer is just there. That's the version worth building toward.
FAQ
When an AI agent does something you didn't expect, can you find out what it did? Only if the context was captured when it ran. A command log gives you the command and little else—not who or what the agent was acting as, under whose approval, or for what declared purpose. Alpacon records those as fields at execution time, on one timeline, so reconstructing an agent's actions is a query, not a week of forensics.
Can you audit what an AI agent did on a production server? Yes—if every agent action runs inside a session that records who or what acted, under what scope, with whose approval, on one timeline. In Alpacon, agents and humans share that timeline, and each entry names the exact credential behind the action. Command logs without that context aren't an audit.
What's the difference between an audit log and an audit trail? A log is a stream of events—what happened. A trail is those events plus the context that makes them accountable: identity, purpose, approval, and outcome, linked to the session and task they belong to. The difference is whether you can answer "who approved that, and why," not just "what ran."
Can Alpacon generate my compliance reports? It captures the privileged-access evidence a report is built from—purpose, approval, scope, and outcome per session—and keeps it query-ready. Auto-generating framework-mapped evidence (SOC 2, ISO 27001, HIPAA) is on the roadmap and scoped to that privileged-access slice; Alpacon isn't your whole GRC platform.
Do humans and agents show up in the same audit? Yes. That's the point of one Work Session timeline: a person or an agent both resolve to an authenticated identity on the same trail, so "who did this?" has one answer instead of three tools to cross-reference.
If you're putting agents on production infrastructure, the audit is the part you'll wish you'd designed in before the incident, not after.
