Long-Lived Agents: Delayed Execution Risk

TL;DR — Quick Summary

The hard security problem in long-lived agents is often not the initial prompt. It is whether attacker-influenced state can survive long enough to trigger a privileged action later.
This is delayed execution risk: low-trust inputs land in memory, queues, summaries, or standing approvals, then re-enter a higher-authority path in a later run.
Recent Zealynx coverage on approval bypass, outbound authority, and indirect prompt injection points to the same root cause: teams review prompts, but fail to review what persists.
Auditors should trace prompt-to-sink across time: who wrote the state, when it was summarized, which approvals remained valid, and what exact sink finally executed.
This matters most in long-lived agents, coding agents, and Agentic DeFi systems, where delayed actions can mutate code, exfiltrate data, or move money.

Introduction

A lot of AI security testing still happens in one session, one prompt, one response.

That is useful, but it misses a more operational failure mode: the attack does not need to win immediately. It only needs to land state that stays alive long enough to be trusted later.

This is the real problem with long-lived agents. They keep memory, task queues, summaries, learned preferences, installed connectors, pending approvals, and scheduled jobs. Once the system persists model-shaped state, the security question changes from “can the attacker influence the current run?” to “can low-trust influence come back later with more authority?”

Under the Zealynx AI audit methodology, this is where authority mapping and trust-boundary tracing matter most. A note written by an attacker on Monday may become a shell command on Thursday. A broad approval granted during one context may authorize a very different transaction after the agent replans. A poisoned memory summary may silently retarget the agent’s “default” destination for outbound actions.

That is not a workflow quirk. It is a security pattern auditors should treat as first-class.

What changed: prompt injection became a persistence problem

The earlier generation of AI reviews focused on direct prompt injection and jailbreaks. That made sense when most systems were stateless chat surfaces.

But the systems now driving real risk are not stateless. They:

write memory
queue tasks
schedule future jobs
retain tool state
reuse approvals
hand work to child agents
keep outbound routing preferences

That changes the audit lens.

Recent Zealynx work already shows the shift:

Indirect prompt injection showed that attacker-controlled content can steer the model indirectly.
AI Agent Approval Bypass: Audit Checks showed that broad approvals often fail to constrain the final privileged action.
AI Agent Outbound Authority: Audit Checks showed that communication tools are real execution sinks, not harmless integrations.

The next step is combining those lessons over time. If the system persists attacker-shaped state, then the exploit path is no longer prompt-to-sink in one run. It is prompt-to-memory-to-queue-to-sink or prompt-to-summary-to-approval-to-sink.

That is why long-lived agent audits need a different testing posture than ordinary LLM app reviews.

The core failure: low-trust state re-enters a high-authority path

The dangerous pattern is simple:

An attacker or mixed-trust source influences the agent.
The influence is written into durable state.
That state is later treated as trusted enough to guide action.
A privileged sink executes under a different context, operator, or time window.

Examples:

a repo issue causes a coding agent to store a “known safe” command template that later reaches shell execution
a support ticket changes a long-lived assistant’s remembered escalation contact, which later becomes an exfiltration path
a poisoned summary causes an autonomous worker to prioritize the wrong counterparty or webhook in a later run
a treasury agent stores a prior swap preference that later re-enters an execution path after market conditions and approvals have changed
a child agent writes task output that the parent later treats as trusted planning input

This is why Zealynx keeps pushing the prompt-to-sink lens. In long-lived systems, the sink is separated from the original influence by time, summarization, and orchestration layers. If an audit only tests the initial interaction, it will miss the real exploit chain.

Delayed execution risk is the issue auditors should name explicitly

The phrase Delayed Execution Risk is useful because it describes the exact failure mode: an attacker does not need immediate execution if they can plant state that later executes under better conditions.

Those better conditions may be:

a broader approval already exists
a human reviewer is no longer in the loop
a child agent is granted stronger tools
the runtime now has different secrets or wallet access
the earlier context has been compressed into a summary that hides provenance
the scheduled run executes during a low-observability period

This matters because teams often overestimate the protection offered by “human-in-the-loop” or “approval required” labels. If the approval is broad, stale, or disconnected from the final sink, time itself becomes part of the exploit chain.

That makes delayed execution risk especially relevant to approval bypass, sink-time validation, and outbound authority.

Why long-lived agents are harder to audit than session-based apps

1. Memory changes trust semantics

A chat message is obviously user input. A memory entry often is not.

Once the system stores a fact, preference, summary, or “learned behavior,” operators start treating it as internal state. That is where memory poisoning becomes dangerous: the original writer may have been low trust, but the later reader treats the state as operational truth.

2. Summaries destroy provenance

A long context is often compressed into summaries, embeddings, or task snapshots. Those layers improve performance, but they also blur who said what and under which authority.

If the runtime cannot show whether a summary line came from an operator, a customer, a web page, a tool descriptor, or a prior model synthesis, the trust boundary is already weak.

3. Schedules create execution windows the attacker does not need to see

A nightly sync, a deferred rebalance, a queue worker, or a retry job can execute hours after the initial influence. That weakens real-time detection and makes forensic reconstruction harder.

4. Child agents and delegators multiply the path

Long-lived systems increasingly decompose work across planners, executors, reviewers, and specialized tools. Each handoff can turn low-trust output into apparently trusted input for the next stage.

5. Standing approvals hide temporal blast radius

The original approval may have looked acceptable in one context. Later, after memory drift or queue mutation, the same approval can authorize a materially different side effect.

This is why Zealynx AI audits treat time, persistence, and delegation as security surfaces, not product conveniences.

What an auditor should check now

This is the part that matters most. If the system persists state across runs, audit the delayed path, not just the first prompt.

1. Which durable stores can low-trust inputs reach?

Map every persistence layer:

memory stores
summaries
vector or retrieval indexes
task queues
retries and dead-letter queues
child-agent outputs
schedules and cron-like jobs
approval caches
connector configuration and defaults

For each one, ask: who can write to this, directly or indirectly?

2. Is provenance preserved when state is read back?

Collect evidence on whether the runtime can prove:

original source of the state
time written
actor or tool that wrote it
whether it was human-authored or model-generated
whether it passed moderation or policy review
whether it was later summarized, transformed, or merged

If provenance disappears at summary time, the trust boundary becomes guesswork.

3. Can persisted state affect a privileged sink without fresh review?

Test whether memory, queue contents, or prior summaries can influence:

shell commands
file writes
Git or CI mutation
outbound messages and webhooks
wallet approvals
router selection
recipient addresses
transaction submission

This should be checked using the same sink inventory used in the AI checklist library, especially for coding agents and Agentic DeFi.

4. Are approvals bound to exact future actions, or just labels?

Inspect whether approvals are:

action-specific
parameter-specific
destination-specific
time-bounded
invalidated when supporting state changes

A standing approval that survives material context changes is a delayed execution risk by design.

5. Does the system revalidate at sink time?

Even if planning and approval happen earlier, the system should still validate at execution time:

exact command
exact file path
exact destination
exact token, amount, and spender
exact router and calldata
exact webhook or recipient set

Get funded for your audit

Core grants cover up to $32k. Growth and Builder tiers available. Rolling applications.

No spam. Unsubscribe anytime.

If those checks are missing, the system is trusting old context to authorize new impact.

6. Can one worker poison another worker’s future state?

In multi-agent systems, test whether outputs from a low-trust or narrower-scope worker can be consumed later by a higher-privilege worker without provenance downgrade or revalidation.

7. Can the operator reconstruct the delayed chain after an incident?

This is the forensics question. You want logs that preserve:

original adversarial input
persisted state artifact
any summary or transformation step
approval artifact, if any
final executed artifact
exact sink event
actor, tool, and timestamp at each hop

If the team cannot reconstruct the time-separated chain, the observability control is weak even if the exploit is suspected.

Coding agents: delayed execution turns repo text into shell risk

Coding agents are one of the clearest examples because they regularly combine untrusted repo content with persistent state and powerful tools.

A realistic chain looks like this:

1Issue comment or README note
2  → agent stores “helpful” task memory
3  → planner rewrites into a reusable command template
4  → queue worker replays the task later
5  → executor runs shell or writes workflow config

The immediate prompt may look harmless. The later sink is not.

This is also where recent MCP-era findings matter. The Anthropic MCP SDK config-to-exec design flaw and Cursor MCPoison / CurXecute coverage show how seemingly normal configuration or descriptor surfaces can become execution paths. In a coding agent, persistence makes those chains harder to spot because the final shell step may happen in a different run, under a different worker, after the original context has been compressed.

For coding-agent audits, Zealynx should now explicitly check whether repo-derived memory can survive long enough to influence later command generation, file writes, CI edits, or PR commentary.

Long-lived agents: the queue is part of the threat model

Many teams threat-model prompts and tools, but do not threat-model queues.

That is a mistake.

A queue entry is a deferred execution artifact. If it stores natural-language instructions, tool arguments, summarised context, or model-authored plans, it can carry attacker influence across time and across workers.

What auditors should inspect:

whether queue entries have immutable provenance
whether arguments are revalidated on dequeue
whether retries preserve the original reviewed artifact
whether dead-letter recovery can replay stale actions
whether queue mutation is logged and access-controlled
whether a lower-trust subsystem can enqueue work for a higher-trust subsystem

In practical terms, a queue is often the missing middle between prompt injection and the final sink.

Agentic DeFi: delayed execution is direct financial blast radius

Agentic DeFi makes this worse because delayed state often meets real authority.

Examples:

a portfolio agent stores a preferred swap route that later resolves to an attacker-controlled path
a governance assistant remembers the wrong delegate or recipient and later submits the action during a scheduled window
a treasury worker reuses a prior approval after destination policy has changed
a bridge or rebalancing task waits in queue until a later run with larger balances and weaker operator attention

This is why Agentic DeFi security cannot be assessed with prompt-only testing. The right question is whether historical state can later influence:

recipient selection
spender approval
route construction
governance payloads
withdrawal timing
threshold notifications
transaction submission

If low-trust state can reach those sinks after the fact, the financial blast radius is real.

Control implications for builders

If you are building long-lived agents, the practical control set is not mysterious.

Separate memory classes by trust

Do not store operator directives, user content, tool output, and model-generated summaries in one undifferentiated memory plane.

Preserve provenance through summarization

Every summary, queue item, or task snapshot should retain source metadata and trust labels, not just content.

Expire or invalidate standing approvals aggressively

A durable approval should die when supporting state, destination, route, or actor context changes.

Enforce sink-time validation everywhere authority exists

The final sink must validate exact parameters independently of prior planning or approval state.

Treat queues and schedules as execution surfaces

They need access control, mutation logs, replay controls, and policy enforcement just like tools do.

Log the chain, not just the endpoints

If your logs only show the first prompt and the final action, you are missing the exploit path in the middle.

These are the kinds of controls Zealynx looks for in AI security audit services and the long-lived agent checklist.

Conclusion

Long-lived agent security is not just prompt security with more uptime.

It is a persistence and authority problem. The attacker wins when low-trust influence survives long enough to be reintroduced under stronger conditions: better tools, broader approvals, weaker review, higher balances, or lower visibility.

That is why auditors should start naming and testing delayed execution risk directly. If you cannot show who wrote the state, how it changed, which approvals stayed alive, and what exact sink finally fired, you do not fully understand the system’s blast radius.

If your team is deploying persistent agents, coding agents, MCP-connected workers, or financial copilots, this is exactly the kind of path a Zealynx AI security audit should trace before production.

FAQ

1. What is delayed execution risk in AI agents?

Delayed execution risk is the failure mode where attacker-influenced or mixed-trust state is persisted first, then later reaches a privileged sink under a different context. The original prompt does not need to win immediately. It only needs to survive in memory, a queue, a summary, or an approval path long enough to be trusted later. See Delayed Execution Risk and Prompt-to-Sink.

2. Why are long-lived agents harder to audit than normal LLM apps?

Because long-lived agents persist state across time. They keep memory, tasks, schedules, retries, and tool state, which means a low-trust write can influence a later run with different authority. That is why Zealynx treats long-lived agents differently from basic LLM application security.

3. Is human approval enough to stop delayed execution attacks?

Usually not by itself. If the approval is broad, stale, or disconnected from the exact final parameters, the control can still fail. This is the same root problem described in AI Agent Approval Bypass: Audit Checks, which is why Sink-Time Validation matters.

4. How does delayed execution risk affect coding agents?

Coding agents often ingest low-trust repo text, store task state, and later execute shell commands or mutate CI. That means a malicious issue, README, or tool output can survive long enough to become a later execution path. See the coding agent checklist and related MCP incident coverage in the AI Security & Hacks Library.

5. Why is delayed execution risk important in Agentic DeFi?

Because historical state can later shape recipient selection, router choice, token approvals, or governance actions. In systems that can influence wallets or treasury workflows, time-separated state drift can become direct financial loss. That is why Agentic DeFi security needs persistence-focused audit work, not just prompt filtering.

Glossary

Term	Definition
Delayed Execution Risk	A failure mode where low-trust or attacker-shaped state is persisted first and later reaches a privileged execution sink under a different context or authority level.
Prompt-to-Sink	The end-to-end path from attacker-influenced prompt or context input to the final execution sink where the AI system can cause a real side effect.
Approval Bypass	A failure mode where a human approval step exists but does not constrain the exact parameters that determine the real security impact of an AI agent action.
Sink-Time Validation	Independent validation at the execution sink on the exact action, destination, and parameters an AI system is about to trigger.

View complete glossary →

Get funded for your audit

Core grants cover up to $32k. Growth and Builder tiers available. Rolling applications.

No spam. Unsubscribe anytime.