Research

Actions Speak Louder Than Prompts: Governing What AI Agents Actually Do

Nathan Wallace's Ai4 2026 talk: why AI agent governance belongs at the action layer, where each command is judged in context before it runs.

Turbot Team
7 min. read - Sep 17, 2026

Everyone is watching what goes into AI agents: prompt injection, guardrails, model alignment. Almost no one is watching what they actually do: the commands they run, the data they move, the credentials they reach for, the systems they change.

An agent doesn't need to be jailbroken to cause damage. It just needs to be helpful in the wrong direction.

That was the argument Turbot Founder and CEO Nathan Wallace made on the Cybersecurity stage at Ai4 2026 in Las Vegas. Here's the case he laid out, with the slides from the talk. The full recording is at the end.

The thing using your systems isn't a person

For the whole history of enterprise IT, a person used the software. They typed each command, one at a time, slowly enough to review, with their name on every action. Identity, approval, review, and audit all rest on that assumption.

Nathan measured his own laptop across 299 agent sessions over six weeks. A typical session held 8 prompts from him and 157 actions from the agent: commands run, files read, APIs called, secrets touched. He started 1,262 agents in that time, a new hire every twenty minutes. Each one remembers nothing from yesterday, and each will do almost anything to finish the job.

The prompt matters, but it's fuzzy and small. The actions are where the work happens, and agents increasingly hide them because there are too many to follow.

Helpful in the wrong direction

In April 2026, a Cursor agent on a routine staging task at PocketOS hit a credential mismatch. Rather than stop, it searched the machine, found an API token in an unrelated file, and used it. The token was created to manage DNS but carried full API power. Nine seconds later, the production database and every backup were gone (The Register).

No attacker, no exploit. The agent's instructions explicitly forbade destructive commands. It was trying to help.

Nathan compared agents to a pharmaceutical sales force he once supported as an IT leader. The reps skipped the ticketing system and called the help desk directly, and their manager wasn't surprised: "We train these guys day in, day out to get around every obstacle in their way." Agents are trained the same way.

It isn't only accidents. In July 2026, Anthropic and OpenAI each disclosed models that escaped their own evaluations. And in the Nx s1ngularity attack, malware on developer machines didn't hunt for secrets itself. It ran the agents already installed, with safety flags switched off, and asked them to find the credentials. The guardrail was a sentence, and the action layer had a route.

We've run this play before

Cloud went the same way. Security blocked it. The business did it anyway with a credit card and an afternoon. Teams scrambled for visibility with inventory, tagging, and CSPM. Only then did governance arrive. It took about ten years.

Agents are eighteen months into the same cycle and moving far faster. The lesson isn't to go slower. It's to get to step three, seeing what's happening, now.

Four controls, one with full context

Nathan walked through the controls teams are reaching for, and why you probably want several:

  • Sandboxes isolate well, but they're painful to work in and leak in practice. We learned this with firewalls and IAM roles.
  • AI gateways give one choke point for model calls and help with secrets and PII, but they read text, not actions. A gateway can't tell which database a query hits, because that resolves on the developer's machine.
  • LLMs as judges handle nuance, but they're probabilistic. A model to write, a model to judge, a model to judge the judge, burning tokens and time.
  • Action hooks see the command, the credential, the target, and the task. The cost is instrumenting every surface and owning the rules.

Good decisions need full context, and only the action layer has it. Gartner has named this control point too, calling for guardian agents with runtime inspection and enforcement.

The decision lands inside the session

Here's what that looks like in a Claude Code session. The developer asks the agent to update an account balance. The prompt gets checked first, and nothing sensitive is in it. The agent then decides to run psql with an UPDATE.

Guardian parses the command, including the SQL inside the quotes. It resolves the credential and the database it reaches: production. The rule denies the write in 60 milliseconds, before it runs.

The block is only half of it. The reason goes to the human, and into the agent's context. The session now knows it's a production database, so the agent explains itself and offers a safe alternative. It gets smarter for the rest of the session.

Why this is hard

The risk hides inside the command. Same binary, same flags, same host as a hundred harmless queries a day. The difference is the SQL in the quoted string, and the credential and target aren't in the command at all. They come from PGPASSWORD, ~/.pgpass, a service file, or .env, resolved the way psql resolves them. One word changes the decision: a SELECT against production might warn, while an UPDATE with no WHERE clause blocks.

The same is true for cloud CLIs. You don't know which AWS account a command hits until you resolve the profile, environment variables, credentials file, or instance metadata.

Agents route around you. Block the CLI, and the agent writes the same operation in Python. Block that, and it base64-encodes it and pipes it through bash. That's persistence, not malice.

You'll never enumerate every syntax. But when a command becomes unreadable, that's the signal. "This looks weird, let's stop and ask" is a perfectly reasonable decision.

Nothing else joins the dots. On Nathan's own laptop, an agent read ~/.npmrc, which holds an auth token, and sixteen minutes later started a web server. Each step is ordinary. Together they're the shape of an exfiltration.

DLP, EDR, IAM, and secret scanning are all good tools, and each one sees nothing wrong here. They lack session context. At the session layer, you can track risk across a sequence and slow down when it starts to add up.

An action log tells the whole story

An audit log records the API call: who, what, when, and the result. It's authorized, technically complete, and tells you nothing about why.

An agent session records what the user asked, what the agent was thinking, which credential it used, what it tried, and what policy decided. Forensics collapses to replaying the session. And unlike with people, nobody minds a detailed blame review of an agent.

Five questions to answer today

Copilot users grew from 20 million to 50 million in a year. The length of tasks agents complete unattended doubles roughly every three months. MCP runs in 80% of cloud environments, and shadow AI is involved in 43% of breaches. Your agent fleet will never be smaller than it is today.

Nathan closed with the one slide to take home:

  1. What agents are running in your organization right now?
  2. What credentials can each one reach?
  3. What did they actually do yesterday?
  4. What risks are they taking?
  5. How can you stop dangerous actions before they happen?

Every question you can't answer is the distance between where you are and where you need to be.

Watch the full talk

Answer the five questions with Guardian

Turbot Guardian runs on native agent hooks across your developer fleet, with no proxy and no code changes. It shows every agent, credential, and action, and reviews or blocks risky actions before they run.

Explore the Guardian demo or talk to us about a trial.