Look for any workflow where a trusted routine reads mutable repository content after installation and then acts on it without a fresh approval step. If the system accepts prose updates as procedure, scans only at install time, and has no control over who can alter the update source, the design is exposed to delayed instruction substitution.
What delayed instruction substitution actually looks like in an AI agent workflow
A delayed instruction substitution issue is rarely about the model being “bad” in the abstract. It is about a trustworthy sequence turning unsafe after the initial trust decision. If an agent installs cleanly, then later reads mutable instructions, prompts, policies, or repo files as if they were still the approved procedure, the original safety check has been bypassed by time.
The key pattern is drift between the moment something was vetted and the moment it is executed. A repository file, release note, task list, or agent instruction file can be harmless at install time and then become a command channel after someone edits it. That is why delayed substitution is a workflow integrity problem as much as it is an AI problem.
For agent-driven systems, the practical question is whether the agent treats the source as data or as live authority. A routine that re-reads mutable content and follows it without fresh approval is effectively allowing post-installation instruction replacement. If the content can change without the system noticing, the agent can be redirected after trust was already granted.
Which workflow conditions expose the weakness
The strongest indicator is a design that combines three traits: the agent consumes prose as operational guidance, the guidance is not frozen or signed, and execution happens later than the validation step. That combination creates a window where an attacker, compromised maintainer, or even an over-broad internal editor can alter the instruction source after the system has accepted it.
Mutable repository content is especially risky when it doubles as policy. For example, an agent may read a markdown plan, a configuration document, or an instruction file, then later act on it during a separate run. If there is no control over who can alter that source, the agent cannot reliably distinguish approved instructions from substituted ones. AI Coding Agents Security Guide is useful background for this pattern because it focuses on how instruction files, secrets, and agent runtime context can become a control surface.
Another tell is when the system scans only at install time or onboarding time. That may be enough for static packages, but it is not enough for agent workflows that keep reusing human-authored text. If the design assumes the text is stable after first review, then later edits become a hidden control bypass rather than a normal content change.
Why this becomes a security problem rather than a simple process issue
Once delayed substitution exists, the agent is no longer executing a stable decision path. It can be induced to follow instructions that were never approved, or that were approved only under different conditions. In practice, this can lead to unauthorized tool use, bad data changes, token exposure, or destructive actions that appear to come from an otherwise legitimate workflow.
The security impact grows when the agent has standing access or broad write capability. Even a small text change can redirect a trusted routine into a high-consequence action, especially if the agent can reach production systems, code repositories, or connected services. AI Agent Authorisation Guide is relevant here because per-action authorization and human approval gates are the control ideas that limit how far a substituted instruction can go.
Delayed substitution also weakens auditability. After the fact, it may be hard to prove whether the agent followed an original instruction set or a later modified version. That makes incident response, blame assignment, and rollback much harder, especially if the system does not preserve versioned evidence of what it actually read before acting. AI Agent Observability, Audit and Incident Response Guide is helpful for understanding what should be logged when agent actions depend on mutable input.
Risk and Threat Considerations
Delayed instruction substitution matters because it turns time into an attack surface. The vulnerable point is not the original approval, but the gap between approval and execution, where a later edit can silently change the meaning of the workflow.
Failure mechanism: The agent trusts mutable instructions after installation, so an attacker or insider can alter the repository content, update source, or instruction file after validation and before execution.
Impact: The agent may execute unapproved actions with legitimate authority, which can lead to privilege abuse, destructive changes, data exposure, or fraudulent automation outcomes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Delayed substitution can redirect an agent into unapproved privileged actions. |
| ASI02 — Tool Misuse | Substituted instructions can steer the agent into unsafe tool calls or workflows. | |
| ASI06 — Memory & Context Poisoning | Mutable instruction sources can poison later agent context after initial validation. | |
| Recommendation — Require per-action authorization and approval before an agent can execute changed instructions. Constrain tool access and validate each tool invocation against the current approved task. Pin and validate context inputs before reuse, and reject untrusted late changes. | ||
| NIST AI RMF | Govern map measure manage | This is an AI risk governance issue involving changing instructions and control verification. |
| Recommendation — Measure whether the agent’s operating instructions remain stable from approval through execution. | ||
| NIST SP 800-53 Rev 5 | AU-9 — Protection of Audit Information | Evidence of what the agent read and executed is needed to detect post-approval substitution. |
| Recommendation — Protect and retain execution evidence that shows which instruction version the agent used. | ||
Practitioner Guidance
What to verify: Confirm whether the agent reads any operational text after installation, build, or approval, and whether that text is version-pinned, signed, or otherwise immutable at execution time. If not, treat the workflow as vulnerable until proven otherwise.
Decision rule: If a repository file can change the agent’s behaviour after review, require a fresh approval or integrity check at the moment of use. If the file is merely descriptive and never executed, the risk is lower, but only if the system truly ignores later edits.
Common mistake: Teams often secure the initial install path and assume the rest of the workflow inherits that trust. For delayed instruction substitution, that is exactly the wrong assumption, because the dangerous change happens after the first check.
Practitioner takeaway: The control objective is not just to approve instructions once, it is to ensure that the version the agent executes is the same version that was approved, with no silent substitution window in between.