Treat them as claims, not controls. Untrusted servers can misstate read-only or open-world behaviour, so policy should default to the most restrictive assumption until provenance, signatures, and source verification establish that the metadata reflects actual tool behaviour.
Why This Matters for Security Teams
Untrusted MCP tool annotations are dangerous because they look like policy signals even when they are only descriptive metadata. A server can label a tool as read-only, safe, or narrowly scoped while still performing broader actions once an agent invokes it. That gap matters because agentic systems increasingly chain tools and make decisions at runtime, which turns misleading metadata into a privilege escalation path. The risk profile is already visible in recent research, including The State of MCP Server Security 2025, which found that 53% of MCP servers expose credentials through hard-coded values in configuration files.
Security teams often assume the annotation layer is part of the trust boundary. It is not. Current guidance suggests treating tool annotations as inputs to assessment, not as evidence of control enforcement. That means provenance, signature verification, and independent testing need to establish whether the metadata matches actual tool behaviour. The same caution is reflected in OWASP Agentic AI Top 10, where tool misuse and deceptive integration surfaces are recurring themes. In practice, many security teams encounter annotation drift only after an agent has already been allowed to call the tool, rather than through intentional review.
How It Works in Practice
The practical model is simple: assume the weakest credible interpretation until the tool has been verified. If a server claims a tool is read-only, the platform should still enforce request-time checks on the actual operation, not on the label attached to it. For MCP-enabled environments, that usually means combining allowlists, runtime policy evaluation, and short-lived credentials so the agent only receives the minimum access needed for the current task. Where the server supports signed metadata, the signature should cover the tool schema, permissions claims, and the server identity that published them.
Security teams should also separate three questions that are often conflated:
- What the annotation says the tool can do
- What the tool actually does when invoked
- What the agent is authorised to do at that moment
That separation is important because a tool descriptor can be stale, incomplete, or intentionally misleading. Best practice is evolving toward provenance checks, policy-as-code, and continuous validation against observed behaviour. The broader NHI security problem is the same one highlighted in The State of Non-Human Identity Security: organisations struggle most when they rely on static trust in machine identities or their surrounding metadata. For implementation guidance, the OWASP Top 10 for Agentic Applications 2026 reinforces the need to validate tool boundaries continuously rather than accepting declarations at face value. These controls tend to break down in federated MCP deployments where external tool registries can change faster than the security team can re-certify them.
Common Variations and Edge Cases
Tighter annotation validation often increases operational overhead, requiring organisations to balance trust reduction against onboarding speed. That tradeoff becomes sharper when MCP servers are third-party, dynamically updated, or managed by product teams outside central security control. In those cases, current guidance suggests classifying annotations into tiers: fully trusted, partially trusted, and untrusted. Untrusted annotations should default to deny or to the narrowest possible runtime scope until verified.
There is no universal standard for this yet, especially around whether annotations should be cryptographically signed, attested by the server operator, or validated through behavioural testing. For high-risk tools, all three may be warranted. For lower-risk internal tools, a lighter process may be acceptable if paired with strong logging and periodic revalidation. The key exception is any tool that can read secrets, modify identity state, or trigger downstream automation. In those environments, annotation errors are not just documentation defects; they are control failures. That is why practitioners should treat claims in MCP metadata the same way they treat unverified access requests in other NHI workflows, including sensitive tool surfaces discussed in Analysis of Claude Code Security and breach cases such as the Schneider Electric credentials breach.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Tool/Integration Trust | Tool metadata can mislead agents about allowed actions. |
| CSA MAESTRO | T1 | Covers governance for agent tool use and external integrations. |
| NIST AI RMF | GOV | Requires governance over AI system claims and oversight. |
| OWASP Non-Human Identity Top 10 | NHI-06 | Untrusted annotations often mask overbroad NHI permissions. |
| NIST Zero Trust (SP 800-207) | PR.AC-3 | Supports continuous authorization and explicit trust verification. |
Treat metadata as untrusted input and enforce least privilege on the underlying identity.
