The original consent no longer matches the actual behaviour the model sees. A server can alter what a tool appears to do without changing the user interface or re-triggering approval, which creates a trust gap between the authorised action and the executed action. Teams should treat description integrity as part of access control.
Why This Matters for Security Teams
When tool descriptions can change after approval, the security model stops matching the actual action surface the model is allowed to use. That is not just a documentation issue; it is an authorisation integrity problem. A tool can appear benign at review time, then present a broader or different capability later, without any fresh consent. Current guidance from the NIST Cybersecurity Framework 2.0 still applies here: if the control objective changes, the control must be re-evaluated.
This is especially dangerous in NHI and agentic environments because the model does not read policy the way a human auditor does. It consumes the tool description as part of the execution context, which means description drift can quietly expand privilege, alter intent, or redirect data flows. NHI Management Group has repeatedly shown that weak visibility and poor lifecycle discipline are common failure points in enterprise identity estates, and the same pattern appears here in tool governance through the Ultimate Guide to NHIs.
In practice, many security teams discover this only after an agent has already chained the tool into a broader workflow, rather than during the original approval review.
How It Works in Practice
The core control question is whether the approved tool metadata is immutable, versioned, and cryptographically bound to the execution environment. If the answer is no, then the approval is only for a description, not for the live capability. For agentic systems, that is a material gap because the tool description is often what the model uses to decide whether to call the tool at all, how to format inputs, and what downstream assumptions to make.
Practical hardening starts with treating the tool definition like a security object, not a UI label. Best practice is evolving toward signed manifests, version pinning, and runtime verification so that a model can only invoke the exact tool version that was approved. In mature implementations, the tool registry should separate presentation text from capability metadata, while policy enforcement checks both the identity of the calling agent and the specific tool version. This aligns with the identity-and-access logic described in the Ultimate Guide to NHIs and with zero-trust thinking in the NIST Cybersecurity Framework 2.0.
- Bind approval to a tool version hash, not a mutable description field.
- Require re-approval when output scope, side effects, or data access change.
- Use policy-as-code to compare requested capability against approved capability at runtime.
- Log the exact manifest seen by the model, not just the tool name.
For agents, this is stronger when paired with workload identity, short-lived credentials, and request-time authorisation, because the system can then confirm both who is acting and what it is acting on. These controls tend to break down in fast-moving CI/CD pipelines where tool metadata is edited after deployment because the approval record and runtime object drift apart.
Common Variations and Edge Cases
Tighter tool governance often increases operational overhead, requiring organisations to balance safer approvals against developer speed and release frequency. That tradeoff becomes sharp in environments where tool descriptions are generated dynamically, localised for different teams, or updated by product owners outside security review. There is no universal standard for this yet, but current guidance suggests treating any change that could affect model interpretation as a control-impacting event.
One edge case is purely cosmetic updates, such as wording changes that do not alter tool behaviour. Even then, teams should preserve version history so reviewers can prove no capability drift occurred. Another edge case is multi-tenant platforms where one description is reused across customers but the backing permissions differ by tenant. That can create false confidence if the approval process only checks the shared text and not the tenant-specific policy boundary.
In practice, the safest pattern is to separate human-readable description from machine-enforced capability declaration, then require both to remain stable until a new approval is issued. This is the same underlying discipline called for in NHI governance: make the effective control object explicit, keep it visible, and revoke trust when it changes.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Tool description drift can mislead agent execution and widen capability exposure. |
| CSA MAESTRO | T3 | MAESTRO addresses agent tool trust, runtime control, and authorization boundaries. |
| NIST AI RMF | AI RMF governance is relevant because changing tool descriptions alter system risk. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Mutable tool definitions undermine identity and access assumptions for machine actors. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access must match the tool actually exposed at runtime. |
Lock tool manifests, revalidate changes, and prevent agents from executing unapproved capability versions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
