Definition drift occurs when the thing that was approved no longer matches the thing that executes. For agentic developer tools, it is the gap between a trusted label and the command or behaviour that later inherits that trust.
What Definition Drift Means in Practice
Definition drift is a trust problem, not just a wording problem. It appears when an approved object, label, or policy target no longer matches what actually runs, so reviewers think they approved one thing while execution follows another.
In security operations, that gap matters because controls are often attached to the approved representation, not to the later runtime behaviour. Once the representation and execution diverge, the organisation may believe it has constrained risk when the effective action path is broader, different, or less visible than intended.
Where Definition Drift Shows Up
The clearest examples involve software or automation that inherits trust from a prior review, then changes meaning over time. An integration, command, policy, or agent may keep the same name, account, or approval history even after its behaviour shifts, which makes static approval records unreliable.
For agentic developer tools, this is especially sharp because a trusted label can become a permission boundary in practice. If the tool later resolves that trust to a different command, endpoint, or action chain, the security question is no longer “was it approved?” but “is this still the same thing that was approved?”
Definition drift is closely related to control-plane mismatch, but it is broader than simple misconfiguration. It can emerge from version changes, reused identifiers, delegated trust, prompt or policy changes, integration swaps, or silent expansion of what an approved component is allowed to do.
Why Definition Drift Is Dangerous
Its danger is that governance, review, and monitoring often operate on the label while the risk lives in the implementation. That creates a false sense of safety, especially where approval, allowlisting, or exception handling assumes the approved name still describes the live behaviour.
In identity and access terms, definition drift can turn an apparently trusted actor, token, or integration into a different access path without a fresh review. The practical result is privilege that outlives the original intent, or trust that is inherited by something that no longer deserves it.
How to Recognise and Contain It
The most reliable check is to compare the approved definition with the current executable reality, not just the record of approval. That means verifying what command, workflow, endpoint, model, or integration is actually invoked when the trusted object runs.
Good containment focuses on narrowing the blast radius of stale trust, reducing silent inheritance, and forcing revalidation when the meaning of an approved object changes. The goal is to make drift visible before it becomes an access or execution problem.
For a useful control reference on this class of problem, Salesloft OAuth token breach illustrates how a trusted third-party integration can become a live access path once the executed behaviour no longer matches the organisation’s mental model of the approved relationship.
Risk and Threat Considerations
Definition drift creates exposure because attackers often benefit when defenders trust the label, the approval record, or the historical relationship more than the current runtime behaviour. If the executed action has drifted, malicious use can hide inside an apparently legitimate path.
Failure mechanism: A trusted object retains its approval status while its effective behaviour changes, letting new commands, permissions, or dependencies inherit old trust without renewed scrutiny.
Impact: Organisations can miss unauthorised execution, over-broadened access, or compromised integrations until the drift is exploited or until post-incident review discovers that the approved thing was never the thing that ran.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Definition drift is controlled by keeping approved baselines aligned with what actually executes. |
| CM-3 — Configuration Change Control | The term describes a change-control gap between approval and executed behaviour. | |
| AC-6 — Least Privilege | Drift can silently expand the effective privileges of an approved component. | |
| Recommendation — Maintain approved baselines and revalidate runtime changes against the recorded configuration. Require formal change control before changes alter the behaviour of approved tools or integrations. Restrict privileges so drifted behaviour cannot inherit broader access than intended. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Definition drift is a governance risk that should be managed as part of enterprise risk strategy. |
| PR.AA-05 — Identity Management, Authentication and Access Control | When trusted labels no longer match execution, access control decisions can be applied to the wrong runtime object. | |
| Recommendation — Include approval-to-execution drift in your risk register and review cadence. Bind access decisions to the actual runtime entity and revalidate identity on material change. | ||
Practitioner Guidance
What to watch for: Treat any gap between the reviewed definition and the live runtime behaviour as a governance trigger, not a documentation issue. If a tool, integration, or agent can change what it executes without a corresponding re-approval step, the trust boundary is already weakening.
Governance implication: Ownership should follow the executable behaviour, not just the original label. The team that approves an integration needs enough visibility to confirm that the object under review is still the object in production, especially when commands or delegated actions can shift over time.
Practitioner takeaway: Review the relationship between approval artefacts and runtime execution as a control in its own right, because definition drift is often the point where “trusted” stops meaning “known.”