Long-running AI agents, the kind that work on a single task for hours or days rather than completing in one exchange, introduce security problems that don't show up in short-lived sessions: credentials that need to stay valid the entire time, context that can drift far from where the task started, and a much wider window for something to go wrong before anyone notices. A short session either succeeds or fails quickly, and a human is usually still watching. A long-running agent might make dozens of decisions unattended, and by the time a person checks in, the agent could be several steps past the point where a bad decision started compounding.
Credentials that outlive a normal session
Long-running tasks often need credentials or tokens that stay valid well beyond a typical session lifetime, which conflicts with the usual security instinct to keep credential lifetimes as short as possible. The practical answer is scoping those long-lived credentials as narrowly as possible in exchange for the extended lifetime, and building in the ability to revoke access mid-task if something looks wrong, rather than granting broad access just because the task will take a while.
Drift compounds over time in ways short sessions don't show
An agent's understanding of its task can drift gradually across a long-running session, small misinterpretations accumulating, memory entries adding up, context windows getting trimmed and losing important early details. What started as a well-scoped task can end up somewhere quite different hours later, without any single decision along the way looking obviously wrong. This is a distinct risk from a single bad decision, and it needs its own detection: periodic checks comparing current agent state and plan against the originally authorized task.
Checkpoints instead of a single approval at the start
A single approval granted at the beginning of a long-running task doesn't account for what the agent might decide to do six hours in, based on things it learned along the way. Breaking a long-running task into checkpoints, points where the agent's plan and progress get reviewed again before continuing, gives you multiple chances to catch drift or manipulation instead of relying entirely on an initial go-ahead that's increasingly stale as the task proceeds.
Interruption and resume need to be safe by design
Long-running agents will get interrupted, by infrastructure issues, deployments, or deliberate pauses, and resuming safely means reconstructing exactly what state the agent was in and what it had already done, not just picking up from the last logged step and hoping nothing was missed. Poorly designed resume logic is a common source of duplicated or skipped actions specifically because the gap between interruption and resume is where assumptions about state tend to go stale.
Monitoring needs a longer memory too
Anomaly detection tuned for short sessions won't catch a slow-building problem in a long-running one. Monitoring for long-running agents needs baselines and alerts that account for gradual change over the task's full duration, not just spikes relative to the last few minutes, since a slow drift toward an unauthorized action can look unremarkable at any single point in time while being clearly wrong across the whole session.
Ownership can't lapse in the middle of a task
A long-running task will sometimes outlast the availability of the person who kicked it off or the team originally responsible for watching it, someone goes on leave, a shift ends, an on-call rotation changes over, and if ownership of a mid-flight agent task isn't explicitly handed off, it can end up running unattended for far longer than anyone intended. This matters more for agents than for conventional long-running jobs, because an unattended agent isn't just idling, it's continuing to make decisions and take actions the entire time nobody's watching. Long-running agent tasks need an explicit, tracked owner at every point in their lifecycle, with a clear handoff process, not an implicit assumption that whoever started the task will still be the one checking on it hours or days later.
Where TELEON fits
TELEON's policy enforcement at the tool-call boundary applies consistently across a long-running session, so credentials, spend, and action scope stay governed by the same rules at hour ten as at minute one, and the audit trail preserves the full sequence of decisions across the task's entire duration, which is exactly what's needed to investigate drift after the fact or to support a mid-task checkpoint review.
Designing the checkpoint cadence, the resume logic, and the drift-detection baselines for a specific long-running workflow is application-level work tied to what that particular task actually involves.
A short checklist
- Scope long-lived credentials narrowly and build in mid-task revocation.
- Add periodic checkpoints comparing current plan against the original task authorization.
- Design interruption and resume logic to reconstruct real state, not just the last log line.
- Tune monitoring baselines for gradual drift over hours or days, not just short spikes.
- Set an explicit maximum task duration or step count, escalating if it's exceeded.
- Review memory and context accumulated mid-task for signs of drift or manipulation.
- Keep a human touchpoint scheduled at intervals, not only at the very start.
Long-running agents trade the safety of frequent human check-ins for genuine efficiency gains, and that trade is often worth making. It just needs to be made deliberately, with monitoring and checkpoints designed for the actual duration of the task, rather than security controls inherited from short-session agents and quietly stretched past where they were ever meant to hold.