Lab Notes

Most SMBs are already running AI somewhere — a Copilot deployment, a chatbot on the website, an LLM summarizing tickets in the PSA. Almost none of them have tested what happens when that AI reads hostile input.

The pattern I keep finding: the AI isn't the vulnerability, the trust boundary is. The agent that can "just read the inbox" can also follow instructions written in the inbox. A poisoned email becomes a command.

What actually helps: enumerate where AI reads untrusted content, scope its tools down to read-only where possible, and log what it does — the same way you'd treat a junior tech with domain admin. Trust, but verify.

Shipping ReACT taught me that "human" input isn't about speed — it's about statistical texture. Real people don't click every 500ms. They click at 487, 523, 441, 610ms, with holds that drift and micro-pauses that correlate with nothing.

Detection systems look at exactly that: interval variance, hold-time distribution, trajectory curvature, and timing-clock consistency. A fixed-interval clicker fails on the first two before it's even fast.

The interesting part for defense: the same fingerprint that makes automation detectable is what you check for when hunting bots. Build the thing and you learn where the detectors look.

The command center I'm field-testing lets me ask "which servers at client-b have pending reboots?" and get an answer in seconds instead of a twenty-minute RMM fishing trip.

The hard part isn't the LLM — it's the plumbing. Agents need read-scoped API credentials, a strict tool surface (query first, act second), and a confirmation step for anything that changes state.

Rule one of letting an agent touch production: every action is a two-party commit. The agent proposes, a human disposes. The day I skip that rule is the day I get to write a very different field note.