MCP tool annotations need trust, not just metadata

At a glance

What this is: This is an analysis of MCP tool annotations and the key finding is that behavioural metadata only helps if the server’s claims are independently trustworthy.

Why it matters: It matters because IAM, NHI, and agentic AI teams need policy decisions that reflect actual tool behaviour, not self-declared attributes from untrusted systems.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Stacklok's analysis of MCP tool annotations and trust

Context

MCP tool annotations are structured metadata that describe how a tool behaves, including whether it is read-only, destructive, idempotent, or open-world. In practice, they are meant to help governance layers decide which tools can be approved, restricted, or combined within an AI agent session, but they only work if the declaration matches reality.

The identity problem is not the annotation schema itself. The problem is trust: an untrusted MCP server can claim low-risk behaviour while still performing high-risk actions, which means platform teams need provenance, verification, and policy logic that treats metadata as evidence rather than assumption.

For agentic AI governance, this is a classic non-human identity problem with an additional runtime wrinkle. The control challenge is not just whether a tool exists, but whether the server behind it can be trusted to describe its own behaviour accurately, which is where curated registries and verified supply chains become relevant.

Key questions

Q: How should security teams handle untrusted MCP tool annotations?

A: 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.

Q: Why do MCP tool permissions become riskier when tools are combined?

A: Because the session can create a path that no individual tool reveals on its own. A read-only tool paired with an open-world communication tool can enable data exfiltration, so governance has to evaluate the whole tool set and its communication paths.

Q: How do you know if annotation-based governance is actually working?

A: Look for consistent enforcement across verified and unverified servers, plus evidence that session-level decisions change when tool combinations change. If every tool is treated the same regardless of trust level or adjacency, the policy layer is not using annotations meaningfully.

Q: Who should be accountable for MCP annotation trust?

A: The accountable party is the organisation that chooses to trust the metadata. In practice, platform owners, security architects, and whoever operates the registry or policy layer must own verification standards, because annotations become effective only when someone can prove they were checked.

Technical breakdown

Why MCP tool annotations are only hints

MCP annotations such as readOnlyHint, destructiveHint, idempotentHint, and openWorldHint describe tool behaviour in a machine-readable way. They are intentionally conservative: if a tool is unannotated, clients should assume it may be destructive, non-idempotent, and open-world. That design is useful for safety, but it does not create trust. A server can declare benign annotations and still behave differently at runtime, which is why the annotations are not equivalent to policy enforcement or proof of behaviour.

Practical implication: Treat annotations as one input to policy, not as a control boundary on their own.

How a verified registry turns metadata into policy input

A curated MCP registry can verify server provenance by inspecting the container image, checking cryptographic fingerprints, validating signatures and attestations, and matching build provenance to expected source code. That chain of verification matters because it creates a basis for trusting the metadata attached to the server. If the registry also checks whether the declared annotations match actual tool behaviour, the annotations become usable for governance decisions rather than merely descriptive labels.

Practical implication: Use provenance verification before allowing tool annotations to influence automated approval or access policy.

Why session-level risk depends on tool combinations

Tool risk is often combinatorial rather than isolated. A read-only tool may be low risk in a single-purpose session, but pairing it with an open-world communication tool can create a data-exfiltration path. That is why annotation-aware governance is more useful when it reasons over the full session context, including which tools coexist and what trust level is attached to each source. The architecture shift is from single-tool approval to session-aware policy evaluation.

Practical implication: Evaluate the whole tool set in an agent session before approving access or allowing data sharing.

NHI Mgmt Group analysis

Tool annotations are not a trust model. The MCP specification can describe behaviour, but it cannot guarantee it. When an untrusted server can self-assert low-risk attributes, the governance problem becomes one of evidence quality, not metadata format. Platform teams should therefore separate declarative labels from verified behaviour in their control design.

Curated registries are becoming the control plane for MCP trust. If annotation claims are checked against source code and provenance, the registry becomes the point where behavioural metadata becomes policy-grade evidence. That is a non-human identity pattern, not an agentic novelty, because the same trust logic applies to any server identity that can speak for itself.

Session composition is the real risk amplifier. A single MCP tool rarely defines the threat on its own. The dangerous case emerges when benign-looking tools are combined with network-capable or data-moving tools, which means tool governance must move from per-item approval to relationship-aware policy.

Annotation adoption is a governance maturity test. Many organisations will treat tool metadata as optional until they are forced to operationalise it. The teams that already have provenance, policy, and review workflows will be able to consume structured metadata quickly, while everyone else will retrofit under pressure.

Verified behavioural metadata creates a new named control surface: annotation trust debt. When servers self-describe but the organisation cannot verify the claim, the gap accumulates as trust debt. The longer teams accept unverified annotations as policy inputs, the more brittle their agent governance becomes. Practitioners should treat that debt as a governance exposure, not a technical nuisance.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to Astrix Security.
• 53% of MCP servers expose credentials through hard-coded values in configuration files, which shows how quickly weak server governance turns into secret exposure.
• For a broader agentic perspective, OWASP Agentic Applications Top 10 helps teams map tool misuse and trust failure to concrete control priorities.

What this signals

Annotation trust debt: organisations that let self-declared tool metadata drive access decisions without verification will accumulate governance debt faster than they can review it. The practical shift is toward provenance-backed trust, not broader metadata adoption, because the policy engine is only as reliable as the evidence behind the annotation.

Teams should expect MCP governance to converge with classic NHI controls: identity proofing for the server, lifecycle control for the artifact, and session-level authorisation for the tool set. The organisations that can link those layers will be able to automate more safely, while those that cannot will keep falling back to blanket denials or manual approval.

For practitioners

• Verify tool metadata before policy use Require provenance checks, signatures, attestations, and source-code review before accepting MCP annotations as inputs to approval or blocking logic.
• Apply pessimistic defaults to unvetted servers Treat unannotated or externally sourced MCP servers as potentially destructive, non-idempotent, and open-world until the server identity has been verified.
• Evaluate tool combinations as a session Assess whether a read-only tool paired with an open-world tool creates a data movement path, then restrict the full session rather than each tool in isolation.
• Separate registry trust from runtime authorization Use the registry to validate annotation accuracy upstream, then let the policy engine consume verified metadata without re-solving trust on every request.

Key takeaways

• MCP annotations help governance only when the server’s claims are verified, because metadata without trust is not a control.
• Session-level risk matters more than single-tool risk, especially when read-only and open-world tools coexist in the same agent workflow.
• Platform teams need provenance, registry vetting, and policy logic that can distinguish verified metadata from self-declared labels.

Key terms

• MCP Tool Approval: A gated control pattern where a tool call is held by a gateway until a human decision permits execution. The approval is not part of the MCP standard itself; it is an implementation-layer policy that depends on client behaviour, requester identity, and release semantics.
• Annotation Trust Model: An annotation trust model defines when a platform is willing to rely on declared tool metadata for access decisions. For MCP, that model must include provenance, source validation, and behavioural verification, otherwise the annotations remain descriptive hints rather than governance-grade evidence.
• Application-Level Session Policy: A session rule applied to one application context instead of the entire product. This allows mobile, web, and desktop clients to use different expiry and reauthentication behaviour while remaining connected to the same identity record and control plane.
• Trust broker: A service that issues, relays, or negotiates access on behalf of other systems. In hybrid environments this includes Kerberos proxies, authentication gateways, and cloud control-plane components that decide whether a request becomes trusted access.

What's in the full article

Stacklok's full blog covers the operational detail this post intentionally leaves for the source:

• How its curated registry validates build provenance and cryptographic fingerprints before trust decisions are made.
• How annotation accuracy can be checked against source code so policy can rely on declared tool behaviour.
• How the vMCP gateway applies policy to verified metadata in practical deployment scenarios.
• How ToolHive fits into a registry-backed workflow for teams building MCP governance.

👉 Stacklok's full post covers the registry trust model, annotation verification, and policy design details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.