Securing Long-Running AI Agents: Persistence and Privilege-Escalation Risks in Agent Runtimes

In May 2026, Google moved Agent Sandbox on GKE from preview to general availability. The signal matters more than the product: long-running autonomous agents are now production infrastructure, not lab experiments. That changes the security question. A short-lived agent that runs, returns an answer and disappears carries one risk profile. An agent that runs continuously, holds standing credentials and accumulates state carries another entirely.

AI agent security for long-running workloads turns on three properties that conventional application security rarely accounts for: persistence, privilege accumulation and privilege escalation. Get those wrong and a single compromise stops being a contained incident. It becomes durable, expanding access that an attacker can sit inside for weeks.

The focus here is narrow: not agents in general, but what happens inside the runtime when one is subverted mid-task, and which controls limit the damage.

What makes long-running agents a distinct security problem

The distinct risk is that the agent never stops. A long-running autonomous agent holds state across tasks, retains the credentials it was issued and keeps reaching for tools and resources on an ongoing basis. Each of those properties extends attacker dwell time and reach in a way a stateless function does not.

Persistence is the first concern. When an agent maintains memory or context across tasks, a compromise of that state survives the task that introduced it. Manipulated context injected during one operation can shape the agent’s behaviour on the next, and the one after that, without any fresh intrusion.

Privilege accumulation follows. Agents are frequently provisioned with broad standing credentials so they can handle whatever a task demands. Those permissions tend to widen over time as new capabilities are bolted on, and they rarely contract. The agent ends up holding far more authority than any single task requires.

Both properties map to the OWASP AI Testing Guide (AITG) and the NCSC AI code of practice, which address agentic runtime behaviour as an assessment concern in its own right rather than as an extension of model security.

How privilege escalation happens inside an agent runtime

Privilege escalation in an agent runtime happens when the agent acts on resources it was never meant to touch. Escalation follows three common routes, and all of them exploit the gap between what an agent is permitted to do and what a specific task actually needs.

One route is credential reuse. An agent issued broad standing credentials can apply them to any operation, so a task that should read one record can instead reach the entire dataset. Nothing about the access looks anomalous to conventional controls, because the credential genuinely authorises it.

Another is tool chaining beyond intended scope. Agents compose tool calls to achieve goals. An attacker who can influence the agent’s reasoning can string those calls into sequences the designer never anticipated, using legitimate tools to reach illegitimate ends.

The last is instruction manipulation through injected context. If untrusted input flows into the agent’s working context, it can rewrite the agent’s effective objectives mid-task. The agent then pursues the attacker’s goal while presenting as a normally functioning workload.

The shared failure underneath all three is the absence of scoped permissions and runtime isolation. Without them, the agent operates with more authority than the moment demands and escalation rarely trips a traditional access alert.

The three controls that limit blast radius

When an agent is subverted, the question is how far the damage spreads before it is caught. Three controls keep that radius small.

Runtime isolation comes first. Each agent should run in a sandboxed environment that constrains what it can see and reach, so a compromise in one agent cannot pivot into shared infrastructure or sibling workloads. Agent Sandbox on GKE reaching GA is recognition that this isolation belongs in the platform, not bolted on afterwards.

Scoped ephemeral credentials come second. Rather than issuing standing privileges that persist across the agent’s lifetime, credentials should be minted per task, scoped to exactly what that task needs and expired when it completes. A compromise then inherits only the narrow, short-lived authority of the task in flight, not the agent’s full historical reach.

Behaviour verification comes third. Expected agent behaviour can be modelled and checked against actual runtime activity, so tool-call sequences and resource access that deviate from the pattern are flagged and stopped. This is what catches tool chaining and instruction manipulation that scoped credentials alone would miss.

Why a control framework matters before you scale

The value of OWASP AITG and the NCSC AI code of practice is that they give CTOs a concrete baseline to assess agent runtime risk before autonomous workloads scale across the organisation. Mapping isolation, credential scoping and behaviour verification to those references turns an abstract worry into an auditable control set.

The timing is the point. Long-running agents are moving into production now. The organisations that assess runtime risk against a recognised framework before scaling will contain compromises that the rest discover only after an agent has been quietly operating against them for a quarter.

This is one strand of the broader agentic security work covered in our AI Security Projects hub, which sets agent runtime risk in the context of wider AI governance and assurance.

Key questions on agent runtime security

What are the main security risks of long-running autonomous AI agents?

Long-running autonomous agents face three core risks: persistence, where compromised state survives across tasks; privilege accumulation, where standing credentials broaden over time; and privilege escalation, where an agent reaches beyond its intended scope. Because the agent runs continuously, a single compromise becomes durable rather than contained, expanding attacker dwell time and reach.

How does privilege escalation happen inside an AI agent runtime?

Privilege escalation in an agent runtime occurs when an agent reuses broad standing credentials, chains tool calls beyond its intended task or has its instructions manipulated through injected context. Without scoped, ephemeral permissions and runtime isolation, the agent can act on resources it was never meant to touch, often without triggering conventional access alerts.

How can organisations limit the blast radius of a compromised AI agent?

Limit blast radius by isolating each agent in a sandboxed runtime, issuing scoped ephemeral credentials per task rather than standing privileges and verifying agent behaviour against expected patterns. Mapping these controls to OWASP AITG and the NCSC AI code of practice gives a structured baseline so a compromise stays contained instead of spreading across the environment.

Assess your agent runtime before you scale

If you are moving autonomous agents into production, the time to check runtime risk is before they accumulate privilege and state. Talk to QL Security about a bespoke AI security project scoped to map your autonomous agent deployments against OWASP AITG and the NCSC AI code of practice.