Authdog
Back to journal

Pin MCP tool manifests

MCP trust configuration now supports pinning specific tool manifests and restricting which tools a connection is allowed to call.

From the changelog: MCP tool pinning and allowed-tools controls

Authdog Team

3 min read
Centered Authdog and Model Context Protocol marks on a grainy teal wash with a pinned dashed orbit

An MCP connection that can call every tool the server advertises today will also call tools added tomorrow. That silent expansion is hard to review after the fact. MCP trust configuration now lets you pin a tool manifest (and its hash) and restrict which tools a connection is allowed to call.

This is the longer note behind the August 15 changelog entry.

How it works

Trust records live on the environment MCP trust store. Each identity (agent or other machine) can carry:

  • Allowed tools — an explicit list the runtime must honor
  • A pinned tool manifest and manifest hash — the reviewed document those tool names came from

The console Agents module is the control-plane editor for that store. The detail sheet has scopes, allowed tools, keys, and a manifest pin panel (hash, optional JSON document, last pinned time). Re-pin when the reviewed manifest changes.

Runtime checks compare the call to the stored allow-list and pin. MCP events such as MCP_TOOL_INVOKED, MCP_TOOL_DENIED, and MCP_TRUST_VIOLATION are the telemetry for those decisions. They are not the same category as console MCP server CRUD.

A later Agents changelog (August 25) made this registry a first-class module. The pinning controls shipped here; the Agents list is where you edit them.

Set it up

In the Authdog console, select an environment that uses MCP, then open Agents:

  1. Open the identity (or register one) that the connection will present.
  2. Set allowed tools to the names you reviewed.
  3. Pin the tool manifest hash (and the manifest document if you store it on the record).
  4. Mark the entry verified only after that review. Revoke it to cut access.

Keep unverified entries out of production traffic. Status is a review signal; the runtime still has to present a key that matches the store.

Trust boundaries

A pin is only as good as the hash you stored. If the server grows new tools and you do not re-pin, those tools stay outside the allow-list — that is the point. If you pin a hash without reviewing the document, you have a checksum, not a review.

Allowed tools authorize machine calls to those tools. They do not replace user authentication or FGA checks on user-owned resources. Do not conflate a registered agent with a published MCP server.

MCP Auth (/dashboard/ai-security) is the playground for a connected server. Trust pinning is on the Agents / trust-store record.

Try it

Pin a manifest on a non-production agent, then call an allowed tool and a tool that is not on the list. Agent identity is described in the August 25 Journal note. The original release note is in the changelog.