A label on a tool is not a lock

MCP tools can carry annotations such as `readOnlyHint`, `destructiveHint`, `idempotentHint`, and `openWorldHint`. They help a client understand whether a tool only reads data, may destructively modify its environment, can be retried safely, or interacts with the outside world.

The names sound almost like a complete security policy. That creates an easy temptation: see `readOnlyHint: true`, remove user confirmation, and let the agent run autonomously. The friendly robot intern has already attached a “safe” label to the button and is preparing for lunch. Security would like it to wait.

The specification calls these fields hints, not guarantees. A server may describe itself incorrectly or deliberately lie. Clients must treat annotations as untrusted unless they trust the server itself. A `readOnly` label therefore does not enforce a write ban, and `idempotent` does not prove that retrying a payment or email is actually safe.

What annotations can do

Hints are useful when each one changes a specific client behavior:

  • `readOnlyHint: true` can remove unnecessary approval for a verified internal tool;
  • `destructiveHint: true` can trigger a warning that displays the exact operation parameters;
  • `idempotentHint: true` can inform whether an automatic retry after a network failure is acceptable;
  • `openWorldHint: true` can warn that a tool contacts external entities and may return untrusted content.

This is a useful risk vocabulary for user interfaces and preflight checks. It makes approval requests concrete. Instead of a generic “allow action?” prompt, the user can see that the agent intends to delete three files, email an external address, or only read an order record.

Annotations can also be inputs to a policy engine, but the decision cannot depend solely on a signal supplied by the server being called. An annotation from an audited internal MCP server pinned in a registry deserves more weight. An annotation from an arbitrary internet server is informational at best.

Risk emerges from combinations of tools

A single tool rarely describes the full risk of a session. Searching corporate email may be legitimate. Web search is ordinary. Sending a message to an external service is also normal. Together, however, they can give an agent three dangerous capabilities: access to private data, exposure to untrusted content, and an external communication channel.

If a webpage or email contains a malicious instruction, the model may interpret it as part of the task. A tool annotation cannot force the model to distinguish data from instructions. It can only help the host notice that the trust context changed and tighten controls: block automatic sending, request approval, or start a new isolated session after external content has been read.

A local model does not remove this risk. Weights and documents may remain inside the company, while the connected agent can still call CRM, email, file-system, or external API tools. The data perimeter and the authority perimeter are different systems.

Where enforceable barriers belong

A production architecture separates hints from enforcement. A practical minimum includes the following controls.

1. A trusted server registry

Connect MCP servers from an approved list and record their owner, version, build hash, and tools. A new version should not inherit trust automatically when its permissions or network destinations change.

2. Authorization at the tool server

The server must verify the user, tenant, object, and action on every call. A model cannot grant itself access with natural language. Tokens should target a specific resource, carry minimal scopes, and expire quickly. Sensitive handlers should verify the authorization context again even if a gateway already performed authentication.

3. A deterministic policy gateway

Before execution, tool calls pass through rules that the model cannot rewrite: approved domains, amount limits, allowed fields, record caps, business hours, and approval requirements. An annotation helps select a policy; it does not replace one.

4. Session risk state

After reading an untrusted website, email, or uploaded document, mark the session as exposed to untrusted data. Increase approval requirements and block paths that combine private-data access with external sending. Clearing the state must be explicit, not triggered because the model says everything is safe.

5. Network and runtime isolation

If a tool does not need internet access, deny egress. If it needs one API, allow only that destination. Run file operations in a dedicated directory or container. Network controls and sandboxing provide enforceable exfiltration boundaries; tool descriptions do not.

6. Verifiable human approval

For irreversible or external actions, show the human the final intent and parameters: recipient, files to be deleted, amount, and account. Approving a broad plan such as “process requests” grants too much latitude.

7. Decision logs, not only result logs

Record the user and agent identity, tool, arguments with secrets redacted, policy outcome, approval, and final result. This makes it possible to determine who delegated an action and why it was allowed. Full tokens and sensitive payloads do not belong in logs.

A two-week pilot

There is no need to build a universal risk platform first. Choose one workflow where an agent reads internal data and uses two or three tools.

Create an operation matrix covering read, create, update, delete, and external send. For each operation, record server provenance, actual technical capability, required rights, reversibility, approval policy, and allowed network destinations. Then compare the matrix with the MCP annotations.

During week one, enable decision logging and require approval for every state-changing operation. During week two, allow automatic calls only for verified reads and bounded idempotent actions. Test incorrect annotations, retries after a timeout, malicious text in an external document, and attempts to send internal data outside the organization.

Useful metrics include:

  • the share of calls blocked by policy;
  • unnecessary approvals per 100 tasks;
  • successful retries without duplicate effects;
  • investigation time using the audit trail;
  • the number of tools and network destinations available to one session.

The economics are straightforward: a few hours spent mapping authority cost less than one accidental bulk email, destructive file operation, or customer-data disclosure. MCP annotations reduce friction and improve the interface, but security spending should prioritize enforceable server policies, isolation, and auditability.

Conclusion

An annotation is an honest label when it comes from a trusted source. It helps a client choose a warning, retry policy, or approval level. It does not keep a door locked.

For a local AI agent, the reliable boundary consists of server-side authorization, a deterministic policy gateway, network restrictions, precise human approval, and delegation logs. The model may propose an action—even enthusiastically—but it cannot assign itself authority.