Re-baseline as part of normal operations, not as an exception process. Drift is expected when models, prompts, and tools change, so the programme needs ownership, review thresholds, and a way to tell legitimate evolution from suspicious deviation. If that cannot be sustained, the control is already underfunded.
Why This Matters for Security Teams
When AI agent baselines drift, the issue is rarely just model quality. It usually signals that prompts, tool permissions, retrieval sources, or workflow logic have changed without a corresponding control review. That creates an audit gap: teams may still believe the agent is operating within approved behaviour while the actual execution path has already expanded. Guidance from the NIST AI Risk Management Framework is clear that AI systems need ongoing measurement and governance, not one-time validation.
For security teams, the practical risk is that drift can look like normal product iteration until it produces unsafe actions, policy bypass, or unreliable decisions at scale. In agentic systems, that can include tool misuse, unexpected data exposure, or changes in how the agent interprets instructions after a prompt, model, or connector update. The same drift may also mask malicious manipulation, such as prompt injection or poisoned context, which is why baseline management must sit inside operational security rather than product experimentation. In practice, many security teams encounter drift only after a failed task, a customer complaint, or an incident review, rather than through intentional monitoring.
How It Works in Practice
Teams should treat baseline management as a recurring control cycle. That means defining what “normal” looks like for the agent, measuring it continuously, and deciding in advance what level of deviation requires review, rollback, or temporary restriction. In agentic environments, the baseline is not just an output pattern. It also includes approved tools, allowed data sources, system prompts, escalation paths, and the identity context under which the agent acts.
A workable process usually includes:
- versioning for prompts, tools, models, policies, and retrieval corpora
- comparison of current agent behaviour against a known-good reference set
- thresholds for acceptable change, with separate rules for expected updates and suspicious deviation
- human review for changes that affect privilege, data access, or external side effects
- logging that links each meaningful action to the model, prompt, and toolchain version in use
This is where the agentic security guidance from the OWASP Agentic AI Top 10 and the adversarial patterns tracked in the MITRE ATLAS adversarial AI threat matrix become operationally useful: they help teams distinguish ordinary variation from security-relevant change. If the agent has access to production systems, the baseline should also include its identity and authorisation posture, because a drift in tool use may actually be a privilege drift. These controls tend to break down when agents are allowed to change prompts, tools, or retrieval sources dynamically without immutable change records, because there is no reliable reference point for what “normal” meant yesterday.
Common Variations and Edge Cases
Tighter baseline controls often increase operational overhead, requiring organisations to balance responsiveness against governance. That tradeoff is real: fast-moving teams want continuous improvement, while security teams need enough stability to tell benign evolution from unsafe deviation. Current guidance suggests there is no universal standard for how much drift is acceptable, so organisations should define thresholds according to the agent’s business impact, data sensitivity, and autonomy level.
Some environments need stricter treatment than others. High-risk agents that can trigger transactions, change records, or interact with privileged tools should generally have narrower baselines and faster review cycles. By contrast, low-impact assistants may tolerate broader behavioural variance if their outputs are always reviewed before use. The same logic applies when teams use the CSA MAESTRO agentic AI threat modeling framework to map how autonomy, tool access, and context sources affect risk.
Emerging practice also distinguishes between drift caused by planned model updates and drift caused by hidden context changes, such as retrieval corpus expansion or third-party tool updates. Those cases should not be treated the same way. Where regulated or safety-critical workflows are involved, teams should document re-baselining as a formal control activity and retain evidence for audit and incident analysis. The challenge is greatest when the agent operates across multiple identities, environments, or business units, because inconsistent ownership makes it hard to decide who can approve a new baseline and who is accountable when the old one no longer matches reality.
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, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | Calls for ongoing AI risk measurement and governance as systems evolve. | |
| OWASP Agentic AI Top 10 | Agentic systems drift through tools, prompts, and autonomy changes. | |
| MITRE ATLAS | Adversarial manipulation can masquerade as ordinary baseline drift. | |
| CSA MAESTRO | Threat modelling helps classify autonomy and tool-access changes in agents. | |
| NIST AI 600-1 | GenAI operational profiles support controls for changing prompts and outputs. |
Correlate drift signals with known AI attack patterns to separate benign change from hostile influence.
