Frequent unexplained deviations, changing tool-by-destination patterns, and policies that are still being edited after each deployment are all signs that the agent’s normal behaviour is not yet stable. If the baseline keeps moving, blocking controls will either miss coercion or break legitimate work.
How to tell the baseline is still moving
The clearest warning sign is instability in ordinary behaviour, not a single bad outcome. If the agent keeps making different tool choices for the same destination, or if the policy has to be rewritten after almost every deployment, the baseline is still absorbing normal variation rather than representing it. At that point, a blocking control is acting on noise.
A mature baseline should make repeated executions look boring in the ways that matter for enforcement. That does not mean the agent becomes static, but the core path from intent to tool use to destination should be predictable enough that deviations are meaningful. When the model of “normal” is still changing week to week, enforcement logic cannot reliably separate new legitimate behaviour from coercive or malicious shifts.
This is why teams often see a false sense of progress after they add more telemetry. More events help only if the baseline is stable enough to compare against. If every deployment introduces new tool routing, new exception handling, or new approval patterns, the control plane never gets a durable reference point. In practice, the first job is to freeze the definition of normal long enough to observe whether it actually holds.
What unstable agent behaviour usually looks like
Frequent unexplained deviations are the most obvious symptom. These include sudden changes in which tools are called, inconsistent destination selection, or request sequences that cannot be explained by a product change, a new workflow, or a known policy update. If the team cannot explain the drift, the baseline is too immature to support hard blocking.
Another sign is destination-sensitive behaviour that changes without a corresponding business reason. An agent that behaves one way for an internal system and another way for a similar external service may be revealing hidden prompt sensitivity, poor routing discipline, or overfitted rules. That kind of variability matters because blocking controls depend on stable path selection, not just stable output text.
A third sign is policy churn after deployment. If every release produces new allowlists, new exceptions, or new “temporary” overrides, the organisation is still learning the agent’s shape in production. That usually means the policy is encoding exceptions to make the system usable, instead of a stable behaviour profile that can safely be enforced. In that state, blocking tends to either break legitimate work or leave useful paths open.
Why blocking controls should wait
Blocking controls work best when the baseline is sufficiently bounded that the team can predict what should be allowed, what should be denied, and what should trigger review. If the baseline is immature, the control becomes brittle. Legitimate work gets blocked because the system has not yet learned the common edge cases, or suspicious work slips through because the policy keeps widening to accommodate new behaviour.
The practical issue is not whether the agent is “intelligent enough”, but whether its behaviour is stable enough to enforce. For blocking to be defensible, the organisation must be able to explain the normal tool chain, the normal destinations, and the normal exceptions. If those elements are still being discovered, a softer control set, such as logging, alerting, gated approvals, and limited blast radius, is usually the safer operating mode.
Teams should also watch for control drift disguised as tuning. When a blocked action is repeatedly reclassified as legitimate just to restore productivity, the policy may be reflecting operational pressure rather than sound security judgement. That is a strong signal that the blocking layer is premature and that the baseline still needs observation, tuning, and validation before enforcement becomes authoritative.
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 | Blocking relies on stable agent authority and predictable access paths. |
| ASI02 — Tool Misuse | Changing tool-by-destination patterns indicate unstable tool selection and misuse risk. | |
| Recommendation — Enforce per-action authorization before allowing agent tool use. Constrain tool choice and review any unexpected tool invocation paths. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | A mature baseline depends on logs that reveal normal versus drifting agent behaviour. |
| AC-6 — Least Privilege | Blocking is safer when the agent's standing authority is already constrained. | |
| CM-3 — Configuration Change Control | Policy churn after each deployment is a sign the control baseline is still changing. | |
| Recommendation — Log agent actions and destination choices to support baseline validation. Limit agent privileges to the minimum needed for the task. Require change control for policy updates that affect enforcement logic. | ||
Practitioner Guidance
What to prioritise: treat unexplained behavioural drift as a baseline-quality problem first, not as a blocking-rule problem. If the same agent keeps taking different paths for the same task, hard denial is likely to be either noisy or incomplete.
What to verify: confirm that the normal tool set, destination patterns, and exception paths are stable across multiple deployments and representative workloads. If policy changes are still required after each release, the model of normal is not yet durable enough for strict enforcement.
Decision rule: if you cannot describe the agent’s ordinary behaviour in a way that survives repeated runs without constant policy edits, stay with monitoring and approval gates. Move to blocking only when deviations are rare, explainable, and operationally bounded.
Practitioner takeaway: a blocking control is only as good as the baseline underneath it, and the safest threshold is not “works most of the time” but “stable enough that a denial means something.”
Related resources from NHI Mgmt Group
- What are the signs that AI agent drift controls are not mature enough yet?
- Why is single-provider AI agent governance not enough for enterprise security?
- How do organisations decide whether AI agent controls are mature enough?
- What are the signs that provenance controls are not doing enough to keep AI output grounded?