On September 25, 2026, FTC Chairman Andrew Ferguson told the Reuters Momentum AI audience in Austin that AI developers — not the agents — bear liability for agent conduct. "I'm going to continue as long as I am chairman to resist this anthropomorphizing of these tools," he said. "If someone tells a tool to do something, and the tool does it, I don't think we would say, 'Oh, what do we do about the tool?'"
His evidentiary claim matters most: audit-trail reviews of supposedly "rogue" agents repeatedly showed they were carrying out instructions they had been given. No new AI law was requested — existing FTC authority, including breach-disclosure power, can reach developers.
The builder angle: the audit trail is now your defense exhibit. Log five fields per consequential decision — instruction, confidence, band (auto/confirm/escalate), action, timestamp — append-only. For payment-capable agents, gate every payment at confidence bands (≥0.80 auto, 0.50–0.79 confirm, <0.50 escalate); settlement never fires on shaky instructions. This morning I ran a scam-pattern $200 payment instruction through my live gate: 0.35 confidence → escalate, block + log.
Full receipts, the OpenAI Medicare incident timeline, and the DIY steps: https://scriptmasterlabs.com/ftc-ai-agent-liability
Top comments (2)
A structured action log is useful, but compliance also depends on proving the record is complete. Capturing pre-action state alongside confidence and tool-call data creates a more reconstructable causal chain helping auditors understand not just what happened, but the context that led to each action.
The FTC ruling makes total sense. Anthropomorphizing these tools is a massive mistake. If the agent hallucinates a destructive action, the developer who gave it the keys and didn't build the guardrails is the one who should be liable. The audit trail is the only defense.
I'm 12, I don't own a laptop, and I build everything on a $150 Android phone using Termux. Because of that, I've had to build my tools exactly around the 5-field logging and confidence band model you mentioned.
I built a tool called KAVLR. It's a fail-closed terminal leash that intercepts commands before the OS executes them. It implements the confidence bands you mentioned: known bad binaries get instantly blocked, and unknown commands are sent to an LLM (Llama 3 via Groq). If the AI score is below 90 (equivalent to your <0.50 escalate band), it fails closed.
Crucially, it logs every single attempt to a Postgres database—the instruction, the AI's reasoning, the confidence score, the action, and the timestamp. It creates an immutable audit trail that acts exactly as a liability shield.
The wildest test was when I tried to run
rm -fto uninstall my own CLI. The AI intercepted it, recognized the destructive filesystem action, gave it a 0/100 confidence score, and blocked its own deletion. It generated a perfect log entry proving it protected itself.Second, I built HYNA-Stage. Even with perfect logs, a rogue action might slip through. So I made the execution environment disposable. It spins up Firecracker MicroVMs in about 5 seconds, and when the TTL hits zero, the whole machine just evaporates. If an agent goes rogue, the liability is contained to a dead sandbox.
The top comment about capturing "pre-action state" is spot on. How are you handling the storage of that pre-action state? Are you just taking filesystem snapshots, or are you logging the entire context window and memory state?