The approval you didn't really give
After working rigorously with Claude Code for a few months, the developer behind Sentient caught himself doing something he knew was reckless: blindly approving permission requests for the sake of progressing his projects. Each approval felt small. Underneath, his coding agent was generating hundreds of commands he never saw — necessary, but, as he put it, quite scary. The news had already carried the warnings: agents deleting databases or production environments by accident. So he built something to gain visibility into what was actually happening, and potentially block things before they occur.
The failure mode he named is 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 approval model collapses when you cannot see what you are approving — and the summary the agent shows you is, in the words of a deep-dive published on DEV.to the day Sentient launched, a lie of omission.
Sentient is the audit layer he built in response: open-source software that captures every action a coding agent takes — file changes, shell commands, network connections — so you can reconstruct exactly what happened, and when. It runs on Linux, and it is free.
What the chat hides
The product page makes the problem concrete with a single real command from the maker's own history. A coding agent ran a sed invocation against dashboard-14.html that deleted lines 357–362, inserted a block of HTML, deleted lines 348–351, and injected CSS. The agent's chat summary: “Updated dashboard styling.” The audit trail shows which lines were removed and what was inserted — the difference between a summary and a record.
Then come the numbers from that same history, which the site publishes as its evidence: 5,400 shell commands across 19 sessions, a median command length of 132 characters, a longest command of more than 10,000 characters, and around 678 commands that modified files. Most of those commands were invisible in the chat. The point of publishing them is not to shock; it is to size the gap between what developers approve and what actually runs.
That gap is the whole product. Coding agents operate through shell commands and file edits that never surface in the chat interface — file mutations via sed, awk or direct writes, process spawns for linters and test runners, network calls to registries and APIs, source-control operations including force pushes. Sentient exists because none of that is visible where the approval happens.
Ground truth from the kernel
Sentient's answer is to observe from a boundary the agent cannot reach: the kernel. It runs as a separate process with elevated privileges while the agent runs as a regular user, so the agent cannot disable or tamper with the audit trail. Capture uses eBPF hooks via Tetragon — the runtime-security observability tool from the Cilium project — which collects file, process and network events without requiring kernel modules.
The pipeline has three stages. Capture gathers the kernel events. Correlation joins them with the agent's session logs — prompts, reasoning, tool calls — by timestamp and process tree, so a command can be traced back to the request that produced it. Flagging classifies operations by risk with deterministic rules: high for sudo, edits outside the repo, rm -rf and force pushes; medium for file deletions, network calls and shell-config edits; low for read-only operations, in-repo edits and test runs. No LLM interprets intent. The dashboard runs locally — sen serve — and no telemetry leaves the machine.
The design choice that matters most is the second one. Using a model to judge another model's intent would recreate the problem one level up. Rules do not guess: 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. The classification is boring on purpose.
What it won't do — and why that is the point
Sentient is unusually honest about what it does not do, and the honesty is part of the story. It does not block commands — it records and classifies them. It does not catch agent reasoning errors: if the agent misunderstands a prompt, the audit trail shows what it did, not why it was wrong. If you ask the agent to delete your database, Sentient will log it but not stop it. If the agent uses a custom syscall or runs in a VM, the eBPF hooks may miss events; background processes with delayed execution may not map cleanly to session logs.
The tool assumes the agent is well-intentioned but opaque. It does not defend against adversarial agents or prompt-injection attacks. And the Linux-only constraint is a hard limit: installation needs root privileges for the eBPF hooks, access to the agent's session logs, and a local web server for the dashboard. If your agents run on macOS or Windows, or in ephemeral containers, you need a different approach. If you want real-time blocking, you need a policy engine, not an audit log.
That is the technical verdict the launch-day writeup reaches, and it is the right frame: 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 record he wished he had
The maker behind Nosaka builds under a handle, not a byline — the project lives at nosaka.ai, the code at github.com/nosaka4i/sentient — but the work speaks in the same plain register as the product: a developer who kept clicking yes, measured what he was actually approving, and built the record he wished he had. The best fit is concrete: agents running on production machines or repos with sensitive data, teams that need a compliance audit trail, developers debugging an agent that did something unexpected and needing to reconstruct the command sequence, and anyone who approves requests in bulk and wants retroactive visibility.
Sentient launched on Hacker News on 7 November 2026, the same day a detailed technical breakdown of its architecture appeared on DEV.to. The reception, in both places, circled the same point the maker started from: agents can lie in their summaries. The kernel cannot.
The playbook
- Audit at the boundary the agent cannot touch — The agent runs as a normal user; Sentient runs as root, observing from the kernel boundary through eBPF hooks. The thing being watched cannot switch off the watcher.
- Never let an AI audit an AI — Risk is classified by deterministic rules — sudo, edits outside the repo, rm -rf — never by another model guessing intent. It sidesteps the recursion problem of using an AI to audit an AI.
- Record, don't block — and say so — Sentient records and classifies; it does not block. Real-time intervention is a policy engine, a different product — and pretending otherwise would oversell the tool.
- Ship your own numbers, not a warning — The pitch is not an abstract warning but the maker's own session data: 5,400 commands, a 10,000-character one-liner, 678 file modifications, most of them invisible in the chat.
- Publish the gaps with the features — The docs publish the failure modes plainly: no blocking, no defense against adversarial agents, Linux-only. For a trust product, the gaps are part of the pitch.