When AI Starts Executing: The Label on the Tool Won't Tell You the Risk

We should stop talking about "AI agents" as if they were one kind of product you buy, name, and put on a diagram. In most companies the agents are already running, and the label on the tool tells you almost nothing about the risk.

This post is for the CISO, the CIO, and the CTO who keep hearing the word "agent" in every vendor meeting and want a working definition that holds up against the real problem: an AI system that no longer just answers, but acts.

The label doesn't tell you the risk

A developer working inside a familiar code editor may already be using an agent. So may an analyst in a chat app that has quietly learned to run multi-step tasks. An agent can be a job that wakes up every morning, does its work, and exits. It can be a workload sitting quietly in your Kubernetes cluster.

None of those labels, editor, command line, chat window, container, tells you how much freedom the AI has or what it can reach. An editor is an interface. A command line is an interface. Kubernetes is a place to deploy software. The question that actually matters is simpler, and more uncomfortable:

Is the system choosing its own steps and carrying them out toward a goal, or is it only answering?

Same window, same product name. One helps a person think. The other executes work on your systems. That gap, not the interface, is where governance begins.

It is worth being precise about one more thing. The AI model is not the whole agent. Around it sits software, often called the runtime or the harness, that connects the model to tools, manages the session, and applies whatever permissions exist. Swapping the model is not the same as changing what that runtime is allowed to do. And a product's visible mode is not a reliable way to spot every execution: vendors are already merging chat and "work" experiences into a single surface.

A short run can leave lasting consequences

The biggest source of confusion is treating "autonomous" and "long-running" as the same thing. They are different dimensions. Autonomy is how much the system can do without a human in the loop. Session lifetime is how long a particular run lasts. A developer can hand a task to an agent and let it work on its own for ten minutes: that is a short-lived run with real autonomy.

And a short run is not a safe run. In those minutes the agent can change files, push code, call an external API, or open a connection. When the run ends, those effects do not politely reverse themselves.

There is a subtler trap with agents that delegate. An agent can hand parts of a task to sub-workers that do their work in their own context and return a short summary. The parent's final "Done" is a summary, not a full account of everything that was executed underneath it. For a security team, "the agent said it finished" and "we can show what it actually did" are not the same statement.

Watching is not the same as controlling

This is the distinction that most AI-governance conversations blur, and the one that matters most for a security leader.

Observability helps you detect, investigate, and attribute what happened. Enforcement can prevent or constrain an action before it happens. Recording a tool call after it ran helps you investigate it. It does not un-run it. An event collected after the fact is not a control.

Both are necessary, and they are not interchangeable. A useful way to think about your estate is to sort each AI surface by what you can actually do to it. Some surfaces you can only observe, a desktop app that emits telemetry lets you see the activity, but there is no point at which you can step in and stop an action. Other surfaces sit in the path of the work, where a control layer can evaluate an agent's next action and deny it before the tool runs, not after.

A control plane for agents is the layer that makes that difference explicit: it observes where observation is all that is possible, it blocks where blocking is possible, and it keeps a record of both. What it should never do is dress up after-the-fact collection as prevention.

Govern the work, not the tool

If the label on the tool is the wrong unit of governance, what is the right one? The work itself. For any consequential agent run, a security team should be able to answer a short list of questions:

These are practical evidence requirements, not a request to read the model's mind. And the evidence has to live somewhere durable and central, feeding your SIEM alongside the rest of your security telemetry, rather than in a local history on a developer's machine, or in the agent's own summary of itself. A record that survives only inside the tool that produced it is not an audit trail.

None of this requires the agent to have "gone rogue" in some dramatic sense. Most of the risk is more ordinary: a prompt injected through untrusted content trying to redirect the agent, or a perfectly well-behaved agent operating inside permissions that were simply too broad. The right risk questions are about reachable data, granted permissions, exposure to untrusted content, and where the enforcement boundary sits, not about how long the session lasted.

The point

The goal is not to label every AI interaction an "agent." It is to recognize the moment AI moves from helping someone think to executing work, and to apply the right control at that moment: observe where you can only observe, block where you can block, and keep the evidence alive beyond the run.

At KonaSense, that is how we think agent governance should work, it should follow the work, not the brand name on the window. The agent run may be temporary. Its consequences are not.