You get a classic post-approval mutation problem. The human approves a benign-looking request, but the resolved filesystem path, config file, or tool definition has changed underneath it. That can turn an intended copy or edit into configuration tampering, unexpected code execution, or secret exposure. The control failed because it checked intent, not the actual effect.
What changes between approval and execution?
The core issue is a time-of-check to time-of-use gap. The approval may be correct for the request as presented, but the underlying target can mutate before the agent acts, so the executed action no longer matches the approved intent. That is why post-approval changes are dangerous in agentic systems: the control validated a description, not the final object.
In practice, the mutable element can be a file path, a prompt template, a config entry, an environment variable, or even the tool definition the agent resolves at runtime. If the agent re-resolves that target later, the approval can be silently redirected into a different effect, including configuration tampering or access to material the user never meant to authorize.
This is most visible when the approval boundary is human-readable but the execution boundary is machine-resolved. A benign request to edit one file can become a write to a different file if symlinks, mounts, working-directory changes, or late-binding lookups are allowed. For agentic systems, the safer pattern is to bind approval to the exact resolved object and action, not to a mutable label.
Why this becomes an authorization and integrity problem
Once the resolved target can change after approval, the problem is no longer just workflow hygiene. It becomes an authorization failure because the agent is effectively reinterpreting the granted permission at execution time. The same gap can also expose secrets if the altered target points at credential material, prompt context, or a tool that has broader access than the original request.
That is why this failure mode often looks like a trust issue around delegated action. The approver intended one bounded outcome, but the system let the runtime environment supply a different one. In agentic workflows, that can turn a normal maintenance step into destructive behavior, unauthorized data exposure, or unexpected code execution when the changed artifact is itself executable or controls execution.
The practical lesson is that approval should be paired with immutable or revalidated execution context. If the content, file hash, path, prompt, or tool schema changes after the decision, the system should treat the approval as stale and require a fresh decision.
What does a safe approval flow need to bind?
A robust design binds the decision to the exact subject being acted on, then verifies that subject again immediately before execution. For file and config operations, that usually means resolving the canonical path, checking the object identity, and validating that the content or descriptor still matches what was approved. For tools and prompts, it means binding to the version, policy, and permissions actually in effect at use time.
When you cannot make the target immutable, the next best control is short-lived authorization with a narrow scope. The approval should be specific enough that the agent cannot swap the target, expand the action, or inherit a broader capability later. This is one reason per-action authorization and just-in-time access matter so much in agent systems.
Good implementations also separate intent from effect. The human approves a named operation, but the runtime must confirm the resolved object, the effective policy, and the final write or call target before it commits. That closes the gap where an attacker, a race condition, or a benign environment change can alter the outcome.
Risk and Threat Considerations
Post-approval mutation creates a high-value abuse path because it lets an attacker or a race condition substitute a different target after the decision has already been made. In agentic systems, that can turn a low-risk request into secret exposure, configuration tampering, or a more privileged action than the approver intended.
Failure mechanism: The system checks the requested intent, then later resolves a different file, prompt, or configuration object at execution time, often because the target is mutable, re-linked, or reloaded after approval.
Impact: The agent can write to the wrong location, execute unexpected code, leak secrets from a changed context, or bypass the human approval boundary entirely.
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 SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Post-approval mutation exploits agent authority at execution time. |
| ASI05 — Unexpected Code Execution | A changed prompt, file, or config can redirect an approved action into execution. | |
| Recommendation — Bind each approval to the exact resolved target and revalidate before the agent acts. Treat target drift as a code-execution risk and block execution until the target is rechecked. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Execution must enforce the granted action against the current object, not a mutable label. |
| CM-5 — Access Restrictions for Change | Configuration or file changes between approval and use can invalidate the original authorization. | |
| SI-7 — Software, Firmware, and Information Integrity | Integrity checks help detect when the target or artifact changed after approval. | |
| Recommendation — Enforce the approved action against the resolved object immediately before use. Restrict and review changes that could alter an approved agent action before execution. Verify the integrity of the target artifact before allowing the approved action. | ||
Practitioner Guidance
What to verify: Confirm that the approved object is the same resolved object at execution time, not just the same name, path, or prompt label. If the target can move, be replaced, or be regenerated, require a fresh approval tied to the new resolved state.
Decision rule: If the action can affect code, configuration, or secrets, treat any post-approval change as a stale authorization event rather than as a harmless update. Revalidation should happen immediately before the write, call, or launch, not earlier in the workflow.
What good looks like: The agent can only act on a bounded, versioned, and observable target, and any mismatch between approved state and runtime state blocks execution by default.
Practitioner takeaway: The central control is not human approval alone, it is approval bound to an immutable or rechecked execution target, with stale decisions rejected before the agent can act.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
