Long-horizon agents: why approving one action at a time is not enough

When an agent works across many steps, the real risk is no longer only in the isolated command. It moves into the full trajectory: goal, accumulated context, changes made, and the ability to undo them.

Context

In recent months, agents have increasingly moved beyond answering in a chat and into longer tasks. They open files, browse pages, use tools, run commands, inspect documents, edit artifacts, and cross several steps before delivering an outcome.

That shift changes the conversation. When AI was mostly answering inside a chat, the main risk seemed to be the content of the response. Once it starts doing work with tools, the risk also appears in the path it follows.

The problem

Many agent architectures still treat security as a set of point controls: can it use the shell? Can it open a browser? Can it write a file? Can it call an API?

Those questions still matter, but they look at isolated permissions. A long-horizon agent can combine several individually acceptable actions and still produce a bad outcome as a sequence.

• It can inspect the right file and then the wrong one.
• It can open a legitimate page, misread the context, and keep insisting on the initial plan.
• It can make a small edit, accumulate decisions on top of that changed state, and end outside the original intent.
• It can ask for point approvals that look reasonable, even inside a trajectory that has already drifted.

Trajectory supervision

The mental model that makes most sense to me today is this: agent security cannot be designed only as tool authorization. It needs to be designed as trajectory supervision.

In practice, this changes the runtime. Instead of only looking at which command was executed, you need clear scope, checkpoints during execution, visibility into what changed, and a real ability to interrupt or roll back.

• Is the original goal still being followed?
• Did the agent expand the scope too much?
• Was there an external action or local change that deserved more contextual approval?
• Is the current state still reversible without high cost?
• Is what happened so far well recorded?

A practical example

Imagine an agent with shell, local files, and browser access helping with a technical routine. Command by command, the flow can look safe: read files, run an inspection, open documentation, edit a file, validate the change, and publish or send the result.

Now look at the same sequence as a trajectory: were the files the right ones? Was the documentation still the right context? Did the edit stay within scope? Did validation cover the real effect of the change? Does publishing still make sense after everything changed along the way?

No isolated action needs to look outrageous for the full flow to become risky.

Approval gates help, but are not enough

Approval gates remain useful, especially when the agent will write to an important file, run an impactful command, access an external resource, publish content, send a message, or execute something irreversible.

But an approval gate alone is still weak when context is missing. If the human sees only an isolated command without enough history, the decision can be shallow.

Good approval is not just friction. Good approval is contextual friction: initial goal, previous steps, affected files, accumulated changes, risk of the next step, and how easy it is to undo the path.

Where this affects architecture

This affects runtime, permissions, observability, and UX. If the runtime does not record state, plan changes, touched artifacts, and interruption points, the human is blind.

• Permissions need to consider where the agent can act, for how long, with which scope, and under which checkpoints.
• Logs need to tell how the task evolved, not only list loose events.
• The interface needs to show what the agent did, what it plans to do, and what has already changed.
• Rollback needs to be simple enough to use before the cost of going back becomes high.

Lessons learned

• In long-running agents, the real unit of risk is the full trajectory.
• Tool permission is necessary, but insufficient without checkpoints, visibility, and rollback.
• Approval gates work well only when they include accumulated context.
• Runtime, observability, and supervision UX matter as much as the model.
• Agent security is operational architecture, not only prompt policy.

Limits and caveats

This reasoning does not replace traditional security controls. Authentication, authorization, environment isolation, human review, logs, data policy, and tool limits remain essential.

It also does not mean every agent needs heavy infrastructure from the first experiment. But if it already touches shell, browser, files, or external actions, it is worth stopping treating it as a clever chat and starting to treat it as a runtime with real side effects.

Conclusion

The longer, more connected, and more autônomous agent work becomes, the less sense it makes to evaluate security only by the current command.

What really matters is the trajectory: how the plan evolves, what changes along the way, where checkpoints exist, and how easy it is to interrupt or undo execution.

A long-horizon agent needs trajectory supervision, not only tool permission.