Sentient: Command Audit Trails for Coding Agents

Coding agents generate hundreds of shell commands per session. You approve a high-level prompt, the agent runs sed, awk, git, and curl in combinations you never see, and your database is gone. Sentient is an audit layer that captures every command at the kernel level, correlates it with the agent’s session log, and flags risky operations before they disappear into the void.

The tool addresses a specific failure mode: blind approval. You ask Claude Code to refactor a module. It requests permission. You click yes. Underneath, it runs 47 commands, deletes three files outside your repo, and modifies your shell config. The chat shows none of this.

The Black Box Problem

Coding agents operate through shell commands and file edits that never surface in the chat interface. A single prompt can trigger:

File mutations via sed, awk, or direct writes
Process spawns for linters, formatters, test runners
Network calls to package registries or APIs
Source control operations (commits, branch switches, force pushes)

The agent shows you a summary. The summary is a lie of omission. Real session data from one developer:

5,400 shell commands across 19 sessions
Median command length: 132 characters
Longest command: 10,000+ characters
678 commands modified files

Most of those commands were invisible in the chat. The approval model collapses when you cannot see what you are approving.

Architecture: Kernel Events + Session Logs

Sentient runs as a separate process with elevated privileges. The agent runs as a regular user and cannot disable or tamper with the audit trail.

Three-stage pipeline:

Capture: eBPF hooks via Tetragon collect file, process, and network events at the kernel level
Correlate: Session logs from the agent (prompts, reasoning, tool calls) are joined with kernel events by timestamp and process tree
Flag: Deterministic rules (not another LLM) classify operations by risk and surface diffs, deleted files, and out-of-repo edits

The agent sees none of this. Sentient observes from the kernel boundary. Tetragon (the eBPF backend) originates from the Cilium project and provides runtime security observability without requiring kernel modules.

Example Command

sed -i -e '357,362d' -e '356a\\ <div class="sevbar">...' \
  -e '348,351d' -e '150a .card-head .sevbar { margin: 0 0 0 auto; }' \
  dashboard-14.html

This command deletes lines 357-362, inserts HTML, deletes lines 348-351, and injects CSS. The agent’s chat summary: “Updated dashboard styling.” The audit trail shows which lines were removed and what was inserted.

Permission Model and Risk Classification

Sentient does not block commands. It records and classifies them. The dashboard flags operations by severity:

Risk Level	Examples	Why It Matters
High	`sudo`, edits outside repo, `rm -rf`, force push	Irreversible or privilege escalation
Medium	File deletions, network calls, shell config edits	Potential data loss or persistence
Low	Read-only operations, in-repo edits, test runs	Expected agent behavior

The classification is rule-based. No LLM interprets intent. If the command touches /etc or runs sudo, it is high risk. If it deletes a file, it is medium risk. If it reads a file, it is low risk.

This avoids the meta-problem: using an AI to audit an AI.

Observability Stack

Data flow:

Agent (userspace)
  ↓ shell commands
Kernel
  ↓ eBPF hooks (Tetragon)
Event stream (file ops, process spawns, network)
  ↓ correlation engine
Session logs (prompts, tool calls, reasoning)
  ↓ rule engine
Dashboard (timeline, diffs, severity flags)

Key components:

Tetragon: eBPF-based runtime security observability, originally from Cilium
Session log parser: Extracts prompts and agent reasoning from chat or API logs
Correlation engine: Joins kernel events with session context by PID, timestamp, and process ancestry
Rule engine: Deterministic classifiers for risk, no model inference

The dashboard runs locally (sen serve). No telemetry leaves your machine.

Failure Modes and Gaps

What Sentient does not catch:

Agent reasoning errors: If the agent misunderstands your prompt, the audit trail shows what it did, not why it was wrong
Malicious prompts: If you ask the agent to delete your database, Sentient will log it but not stop it
Kernel bypass: If the agent uses a custom syscall or runs in a VM, eBPF hooks may miss events
Correlation failures: If the agent spawns background processes with delayed execution, the session log may not map cleanly to kernel events

The tool assumes the agent is well-intentioned but opaque. It does not defend against adversarial agents or prompt injection attacks.

Deployment Shape

Sentient is a Linux-only CLI tool. It requires:

Root privileges to install eBPF hooks
Access to the agent’s session logs (file path or API)
A local web server for the dashboard

Installation:

# Install Tetragon (eBPF backend)
curl -LO https://github.com/cilium/tetragon/releases/download/v1.0.0/tetragon-linux-amd64
sudo install tetragon-linux-amd64 /usr/local/bin/tetragon

# Install Sentient
curl -LO https://nosaka.ai/sentient/releases/sentient-linux-amd64
sudo install sentient-linux-amd64 /usr/local/bin/sen

# Start audit capture
sudo sen capture --agent-log ~/.claude/sessions.jsonl

# Start dashboard
sen serve

The agent runs as your normal user. Sentient runs as root. The agent cannot disable the audit trail.

When to Use This

Good fit:

You run coding agents on production machines or repos with sensitive data
You need a compliance audit trail for agent actions
You want to debug agent behavior without re-running sessions
You approve agent requests in bulk and need retroactive visibility

Poor fit:

You run agents in ephemeral containers (eBPF setup overhead is high)
You need real-time blocking of dangerous commands (Sentient logs, does not block)
You trust your agent completely and do not care about the command layer
You run agents on macOS or Windows (Linux-only)

Technical Verdict

Sentient solves the observability gap for coding agents. It does not solve the trust gap. If you blindly approve agent requests, you will still blindly approve them. But you will have a forensic record of what happened.

The kernel-level capture is the right boundary. Agents can lie in their summaries. The kernel cannot. The rule-based risk classification avoids the recursion problem of using AI to audit AI.

The tool is most useful in two scenarios: compliance (you need an audit trail) and debugging (the agent did something unexpected and you need to reconstruct the command sequence). It is less useful for real-time intervention. If you want to block dangerous commands, you need a policy engine, not an audit log.

The Linux-only constraint is a hard limit. If your agents run on macOS or in cloud VMs, you will need a different approach.

Agentic AI, minus the noise.