A security failure mode where content approved at installation changes later but is still treated as trusted by the system. In agentic environments, this can let a third party alter behaviour after the original approval decision without triggering a new trust review.
What post-install instruction drift means
Post-install instruction drift is a trust-boundary failure: content approved at installation later changes, but the system keeps treating it as if nothing meaningful changed. The result is stale approval attached to a moving target.
How drift breaks the original trust decision
The core problem is not that the initial instruction was unsafe, it is that the approval signal no longer matches the current content. If the system does not re-evaluate the object after modification, later behaviour can inherit trust that was only valid for the earlier version.
That makes drift especially important in software delivery, agent workflows, and third-party integrations where one party can update instructions, configuration, or linked content after the original review. The user or platform may believe it is still enforcing the same approved state when the effective behaviour has changed.
Why this matters in agentic and integration-heavy environments
In agentic systems, installation often creates an implicit permission story, the installed instructions are assumed to remain the same until revoked. Drift breaks that assumption by letting post-approval edits alter tool use, routing, external calls, or policy interpretation without a new review.
This is closely related to the risk of stale trust in third-party components, because the danger is not only what was installed, but what the installed object can become later. A seemingly benign integration can be turned into a different control surface if updates are not re-checked against the original trust decision.
For a concrete example of how token-bearing integrations can become a post-approval exposure, see Salesloft OAuth token breach.
What makes instruction drift dangerous operationally
Drift is dangerous because it is easy to miss. Systems often verify installation once, then assume the object remains trusted, even though later edits may change security posture, permissions, or downstream behaviour.
That creates a gap between policy and reality: logs, allowlists, and human review may all refer to the original approved state while the live object now behaves differently. The security impact grows when the changed instruction can influence access tokens, external actions, or delegated behaviour at runtime.
Risk and Threat Considerations
Post-install instruction drift creates a time-of-check to time-of-use problem for trust decisions. The initial approval can become stale while the live content, configuration, or agent instruction continues evolving.
Failure mechanism: An attacker, third party, or careless maintainer changes the installed material after approval, and the system fails to detect that the trusted object is no longer the same one that was reviewed.
Impact: Previously approved content can redirect behaviour, expand access, or trigger unsafe actions without a fresh trust decision, increasing the chance of abuse, unauthorized execution, or silent policy bypass.
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 and OWASP Non-Human Identity Top 10 address 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-install drift can let changed agent instructions retain prior trust and authority. |
| Recommendation — Bind agent approvals to immutable versions so changed instructions cannot inherit old privilege. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party post-install changes can alter trusted behaviour after initial approval. |
| Recommendation — Revalidate third-party integrations after updates to prevent trusted behaviour from drifting. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Drift is a change-control failure where approved content changes without renewed review. |
| SA-3 — System Development Life Cycle | Supplier-delivered updates can alter installed behaviour after acceptance and need governance. | |
| IA-5 — Authenticator Management | Drift can expose or alter token-bearing instructions and other identity-enabling material. | |
| Recommendation — Require change approval for any modification to installed content that affects trusted behaviour. Evaluate supplier updates for trust impact before they replace an approved installed state. Rotate or revoke credentials when installed content changes in ways that affect trust. | ||
Practitioner Guidance
What to watch for: Treat any object that can change after approval as a live trust asset, not a one-time installation artifact. The important question is whether the current version still matches the version that was reviewed, signed off, or allowed.
Governance implication: Approval should be bound to version, hash, or another immutable reference so that a change forces reassessment rather than inheriting old trust. If the system cannot detect meaningful post-install changes, the trust model is weaker than it appears.
Related resources from NHI Mgmt Group
- What breaks when a trusted npm package can execute post-install code?
- What breaks when teams rely only on post-install hooks to detect malicious packages?
- What breaks when Linux package installs are allowed to reach out to npm or Bun during build or post-install steps?
- What breaks when organisations rely on post-install scanning instead of blocking packages up front?