They should keep a sparse set of authoritative behaviour specs, tie each one to a standing eval, and treat disagreements between runtime prompts and the spec as a governance defect. That gives the team a durable control for drift, rather than a static document that quickly becomes stale.
How to govern agent behaviour as models and tools change
Agent governance works best when it is anchored to a few durable behaviour contracts, not to prompts that drift with each model release or tool change. The governance job is to keep the agent’s intended authority, boundaries, and acceptable outputs stable enough to test, review, and audit even as the implementation underneath it evolves.
A sparse spec is useful because it creates a stable reference point for both engineers and reviewers. When the model, retrieval stack, or toolset changes, the team can re-run the same standing evaluation against the same expected behaviour and see whether the agent still acts within policy, rather than debating whether a rewritten prompt still “sounds right.”
That also makes disagreement actionable. If runtime behaviour diverges from the authoritative spec, the issue is not just a quality bug, it is a governance defect that can change access, escalation, or tool use. Treating the spec as the source of truth prevents local prompt edits from silently redefining what the agent is allowed to do.
What a durable behaviour specification should contain
The most useful spec is usually short, explicit, and testable. It should define what the agent may do, what it must not do, what evidence it needs before acting, and what requires escalation or human confirmation. That keeps the spec tied to observable behaviour instead of vague aspirations like “be helpful” or “be safe.”
The spec should also express the decisions that matter when the environment changes. For example, if a tool is added, removed, or broadened, the spec should say whether that creates a new action path, a new approval requirement, or a narrower permission boundary. A good spec is written so that changing the underlying model does not require rewriting the policy intent.
Standing evaluations are the other half of the control. They should measure the same scenarios repeatedly, including edge cases where the model might comply with the prompt but violate the policy intent, such as taking a shortcut through a newly available tool or over-generalising from a previous conversation. That makes drift visible before it becomes an operational habit.
How to keep governance current as tools and models evolve
As the system changes, update the control plane, not just the prompt text. Version the behaviour spec, bind each version to evals, and require review when there is a model upgrade, a tool integration change, a new action path, or a change in delegated authority. The question is not whether the agent can still produce a plausible answer, but whether its authority still matches what governance approved.
For teams building agents on protocol-driven tools, the same principle applies to the surrounding trust boundary. If the tool surface changes, the governance artefact should change with it, so the team can verify whether the agent is now able to observe, request, or execute more than before. MCP security guidance is a useful reminder that tool access, authorization, and gateway design can shift the practical boundary even when the agent prompt looks unchanged.
As agent estates grow, the governance challenge becomes consistency across many agents, many tools, and many product cycles. The agentic AI identity maturity model and agentic AI identity guidance both reinforce the same operational idea: define identity, delegation, and ownership clearly enough that policy can be checked against reality, not assumption.
For broader security practice, the control pattern maps naturally to agentic risk management and governance frameworks. OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both support a posture where behaviour, authority, and oversight stay aligned as the system changes.
Risk and Threat Considerations
When agent behaviour is governed by prompts alone, the organisation is exposed to silent drift. A new model may follow the same instruction differently, a new tool may expand reachable actions, or a new integration may introduce a capability that was never reviewed. The failure is often not a dramatic break, but a gradual widening of what the agent can do without a matching governance decision.
Failure mechanism: Runtime instructions, model behaviour, and tool availability diverge from the approved behaviour spec, so the agent can still appear to work while crossing an unreviewed authority boundary.
Impact: That drift can lead to unauthorised actions, inconsistent escalation, unsafe tool use, or control failure that is only discovered after an incident or audit challenge.
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 surface, NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent authority drift can create unreviewed privilege changes. |
| Recommendation — Bind agent privilege changes to reviewed evals before expanding runtime authority. | ||
| NIST AI RMF | GV.4 — Map, Measure, and Manage AI Risks | Governing changing agent behavior requires ongoing risk measurement and control. |
| Recommendation — Re-run standing evaluations whenever models or tools change. | ||
| ISO/IEC 42001:2023 | A.6.2 — AI risk treatment | Behaviour specs and evals are AI risk treatments that need versioned governance. |
| Recommendation — Version behaviour specs and revalidate them after material system changes. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Model and tool changes need controlled review because they alter governed behaviour. |
| CA-7 — Continuous Monitoring | Standing evals function as continuous checks for behaviour drift. | |
| Recommendation — Require approval for any model or tool change that affects agent authority. Monitor production agent behaviour against the approved spec on an ongoing basis. | ||
Practitioner Guidance
What to prioritise: Treat the behaviour spec as a governed asset, then tie every material agent change, model upgrade, or new tool path to a standing eval before release. If a change cannot be tested against the existing spec, it is not ready to inherit production authority.
What to verify: Confirm that the spec covers the agent’s current tool surface, escalation rules, and approval boundaries, not the version that existed when the agent was first launched. The most common mistake is allowing the prompt to evolve informally while the approval model remains frozen.
Practitioner takeaway: The strongest control is not a more elaborate prompt, it is a stable policy reference that can be measured against live behaviour whenever the model or tools change.
Related resources from NHI Mgmt Group
- How should organisations govern agentic risk as tools and models change?
- How can organisations reduce the blast radius of compromised agent identities?
- How should organisations govern AI traceability when models and data change quickly?
- How can organisations govern AI tools that may route prompts to different models?