MCP tool annotations need trust, not just metadata

At a glance

What this is: Stacklok argues that MCP tool annotations become useful governance inputs only when their claims are trustworthy, not when they are treated as self-certifying metadata.

Why it matters: IAM, NHI, and agentic AI teams should treat annotation trust as a supply chain and policy problem, because unsafe metadata can distort approval, containment, and session-level control decisions.

Context

MCP tool annotations are a governance signal for agentic systems, but the signal is only useful when the metadata accurately reflects what a tool can actually do. The primary issue is trust, because policy engines that rely on declared behaviour without verification can be misled by servers that claim safety while still altering state, reaching external systems, or exposing data.

For identity teams, this is not a syntax problem. It is an agentic governance and supply chain problem where tool metadata, server provenance, and session composition all influence whether access can be approved, constrained, or blocked with confidence.

The article’s central question is how structured tool metadata becomes trustworthy enough to drive policy. The answer is that provenance and verification have to sit upstream of enforcement, otherwise the governance layer is forced to assume the worst for every tool regardless of what the annotation says.

Key questions

Q: What breaks when MCP tool annotations are treated as trustworthy without verification?

A: Policy breaks because annotations are only hints unless the declaring server has been proven trustworthy. An unvetted server can claim read-only behaviour and still alter state, so enforcement based on metadata alone creates a false allow decision. The control must validate provenance and source code before trusting the claim.

Q: Why do MCP tool risks increase when multiple tools are used in the same agent session?

A: Risk increases because a safe-looking tool can become dangerous when paired with another tool that can move data externally. The session, not the isolated tool, is the real security boundary. Governance has to evaluate the combined capability set before approving or constraining the workflow.

Q: How should teams decide whether to trust MCP tool metadata from a server?

A: Teams should trust metadata only when the server has passed provenance verification, signature checks, and annotation validation against its source code. If those checks are missing, the safest posture is to treat the annotations as untrusted claims and enforce conservative defaults. Trust should be earned upstream, not assumed at enforcement time.

Q: What is the difference between tool annotations and tool trust in agentic governance?

A: Tool annotations describe claimed behaviour, while tool trust is the verified confidence that those claims match reality. An annotation can say a tool is read-only, but trust only exists when provenance and code review confirm that it cannot mutate state or reach outside its intended boundary.

Technical breakdown

Why unverified MCP annotations are not enforceable policy

MCP annotations such as readOnlyHint, destructiveHint, idempotentHint, and openWorldHint are descriptive metadata, not cryptographic guarantees. That distinction matters because a client cannot infer trustworthy behaviour from self-declared labels alone. The MCP spec correctly defaults unannotated tools to the most conservative posture, but that posture still leaves a governance gap if an untrusted server can lie about its properties. In identity terms, this is delegated trust without delegated proof. A policy engine that consumes unverified annotations is making authorisation decisions on claims, not evidence.

Practical implication: Treat annotations from unvetted servers as advisory only, and do not convert them into allow decisions without upstream verification.

How provenance verification turns tool metadata into a trust input

Stacklok’s approach ties annotation trust to a verifiable software supply chain. That means examining the container image, checking signatures and attestations, and validating that the running artifact matches the expected source. Once that chain is established, the annotation claims can be treated as policy inputs because the server’s identity and build provenance have been checked against something stronger than its own declarations. This is the same control logic identity teams already use when they distinguish between asserted identity and authenticated identity. In MCP governance, the metadata only becomes actionable when the server behind it is authenticated by provenance.

Practical implication: Require source-to-artifact verification before using tool annotations as policy inputs in production sessions.

Why session-level risk depends on tool combinations, not single tools

A tool’s risk changes depending on what else is present in the same agent session. Read-only access to private information may be acceptable in isolation, but paired with an open-world tool that can send data externally it creates a credible exfiltration path. That is why combinatorial policy matters more than static tool classification. The governance question is not just what a tool can do, but what it can do in relation to the rest of the session. For agentic systems, the control boundary shifts from the individual tool to the session composition and the trust level of every participant in that composition.

Practical implication: Apply policy to the full tool set in a session, not to each tool as if it were isolated.

Threat narrative

Attacker objective: The attacker objective is to get a governed agent to approve or combine tools in ways that enable unauthorized data movement or destructive action.

1. Entry occurs when an agent session loads tools from a server whose annotations are treated as trustworthy without independent verification.
2. Credential or data access becomes risky when a tool marked read-only is allowed to operate in a session that also contains open-world communication capability.
3. Impact follows when the combined tool set enables state change or data exfiltration under a false safety assumption.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trustworthy tool annotations are a supply chain problem before they are a policy problem. MCP makes metadata the language of tool governance, but language is not evidence. If a server can declare itself read-only while behaving destructively, then the control surface has already shifted upstream to provenance, signing, and verification. Practitioners should treat annotation trust as part of the identity supply chain, not as a UI or schema concern.

Annotation syntax without verification creates a false sense of enforceability. The article’s core insight is that open-world, destructive, and idempotent hints only have operational value when the declaring server is known to be truthful. That means policy engines must distinguish between asserted behaviour and verified behaviour. The implication for agentic governance is simple: metadata does not reduce risk until the underlying server identity has been established.

Open-world tool combinations create an identity blast radius that single-tool review misses. A read-only tool can become dangerous when paired with a tool that can transmit data externally, because the session becomes the unit of risk. This is where agentic governance diverges from traditional application controls: the session composition, not the isolated tool, determines whether a workflow can leak or mutate data. Practitioners need session-aware controls, not tool-by-tool optimism.

MCP governance will increasingly split between trusted registries and everything else. The adoption gap is not whether annotations exist, but whether organisations can verify them at scale. Curated registries that validate source code, provenance, and annotation accuracy can turn metadata into a usable control signal; unvetted sources will remain under pessimistic defaults. The practical conclusion is that platform teams should design for a two-tier trust model now, before annotation-driven policy becomes table stakes.

Verified annotation claims will become a named governance concept: trust-brokered metadata. In this model, the registry is not just a catalogue but the authority that converts self-declared tool behaviour into policy-grade input. That concept matters because it cleanly separates description from proof and makes the trust boundary explicit. Identity teams should adopt the same discipline for agentic toolchains that they already expect for privileged service identities.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Trust-brokered metadata: MCP governance is moving toward a model where annotations matter only after provenance, signing, and code validation establish that the declared behaviour is real. That changes the control point from policy syntax to upstream verification, which is the right place for agentic systems to settle trust.

Platform teams should expect session-level decisioning to replace single-tool approval logic as the default pattern for agentic environments. Once open-world tools can coexist with data-reading tools, the meaningful question becomes whether the full session can exfiltrate or mutate information, not whether one tool looks harmless in isolation.

The verification burden will not disappear as annotation adoption grows. Organisations that do not build a trust model now will end up retrofitting governance around metadata they cannot reliably defend, while those that do will be able to use tool annotations as a practical policy layer.

For practitioners

• Validate annotation claims against source code Require provenance checks, signature verification, and source-to-artifact matching before any tool annotation is allowed to influence policy decisions.
• Treat unvetted servers as pessimistic by default Keep destructive, non-idempotent, and open-world assumptions in place until the server has been verified through a trusted registry or internal review.
• Apply session-level policy to tool combinations Evaluate whether a read-only tool becomes risky when paired with open-world communication or other external reach in the same session.
• Build a trusted registry for MCP servers Curate approved servers, verify their provenance, and make annotation accuracy part of the acceptance criteria for production use.

Key takeaways

• MCP tool annotations are useful only when their claims are verified against provenance and source code, not when they are accepted as self-certifying labels.
• The real risk comes from tool combinations inside an agent session, where a read-only tool can become dangerous when paired with open-world access.
• Teams need a trust-brokered registry model if they want annotation-driven policy to be enforceable in production.

Key terms

• Tool Annotation: Tool annotation is metadata attached to an MCP tool that helps the agent harness understand how the tool should be treated. Annotations can flag read-only behavior, destructive actions, or open-world content, allowing systems to add confirmation steps and reduce unsafe execution.
• Trust-Brokered Metadata: Trust-brokered metadata is information that becomes policy-grade only after an independent trust process validates it. For MCP, that means provenance checks, code inspection, and registry controls convert self-declared tool claims into inputs a governance layer can safely use.
• Session-Level Policy: Session-level policy is a rule set that applies only while a user, workload, or agent session is active. It governs actions such as access, step-up checks, time limits, and transaction approval. Technically, it evaluates context during an authenticated session and can change permissions without altering the underlying account or role.
• Provenance Validation: A control approach that verifies where a payment, credential, or approval came from, who authorised it, and whether its path matches expected business logic. It is stronger than appearance-based review because it anchors trust in lineage and context, not visual similarity.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.