The agent passed review. Then its tool catalog changed.

AI agent tool capability drift begins when the agent that entered production is no longer operating against the same callable capability set that was reviewed. The model, prompt and agent identity can remain unchanged while an MCP server, gateway target or tool registry quietly alters what the agent is able to discover and invoke.

The production review is unremarkable.

A customer-service agent can look up an account, retrieve open cases, read billing history, draft a response and create an internal escalation. Six tools appear in the approval packet. Security has checked their credentials. Operations has reviewed the possible actions. The business owner signs off.

Three weeks later, the agent still has the same model.

Its instructions have not changed.

Its identity is the same.

But tools/list now returns seven tools.

Another team has added a refund API to an MCP gateway that both agents use. The integration was legitimate. The new tool was intended for a separate workflow. Nobody edited the customer-service agent.

It can nevertheless see a capability that did not exist when its production review was completed.

Whether policy ultimately allows the call is a separate question. The immediate governance problem is that the object that was approved and the object now running in production no longer have the same capability surface.

The review packet still says six tools.

Production says seven.

The tool catalog is part of the deployed agent even when it lives elsewhere

Enterprise agents increasingly discover capabilities instead of carrying every integration inside their own application package.

That makes tool inventory partly external to the agent.

Amazon Bedrock AgentCore Gateway, for example, can aggregate multiple MCP targets into a single virtual MCP server. Clients see a consolidated tools/list response containing capabilities from the attached targets. AWS also supports explicit synchronization when an MCP server adds, removes or modifies tools, prompts or resources.

Adding a gateway target can therefore alter the catalog presented to an agent without changing the agent’s source repository. Updating an existing MCP server can change that catalog after synchronization. In dynamic listing mode, AgentCore can retrieve server capabilities when an MCP operation is invoked rather than relying on an earlier indexed catalog.

Google’s Agent Registry exposes the same governance problem from another direction. It serves as a catalog for MCP servers and their tools, and its documentation provides for updating tool definitions when a server adds tools or changes existing schemas. For manually registered servers, the uploaded specification is replaced with the new tool definition set.

A production review that records the agent version while leaving the callable-tool state implicit has captured only part of what entered production.

A seventh tool is the easy case

The customer-service review team can spot the new refund tool quickly because the catalog has grown from six entries to seven.

More difficult changes do not alter the number of tools.

A tool called customer_account might still exist under the same name after its input schema changes. A formerly required parameter can become optional. An enumeration can gain another action. A target behind the tool can change. A read-oriented operation can acquire a write path.

MCP tool discovery exposes names, descriptions and parameter schemas rather than merely an opaque list of integrations.

A capability diff can therefore examine more than tool count:

• tool added or removed;
• schema expanded or narrowed;
• target changed;
• credential path changed;
• tool semantics changed;
• policy attached to the action changed.

The last two require more judgment than a source-control diff.

A renamed description may be harmless. A new optional execute=true parameter may not be.

The review process therefore needs a definition of material capability change, not merely a checksum of tool metadata.

The approved capability baseline needs to survive the meeting

At the original production review, the six tools are visible on a slide.

The reviewed set needs to survive in a form that production systems can compare with what the agent sees later.

For this agent, the baseline could contain the gateway and target identifiers, tool names, input schemas, relevant action classifications and the policy or authorization context expected to govern them. The organization can then assign that baseline a version or immutable review identifier.

This is an architectural pattern rather than a feature mandated by MCP.

A screenshot saying Approved tools: 6 becomes stale as soon as the catalog moves.

A capability manifest saying exactly which six tools, under which definitions, were reviewed can be diffed against the new state three weeks later. The production review has then created durable control data rather than a record that can only be read by a person.

Discovery and authorization are different control layers

The security team investigates the refund tool and finds that the agent can discover it, while current policy would block most refund calls.

AWS makes this separation explicit in AgentCore Gateway with Policy. Tool listing is treated differently from an actual invocation. A principal sees tools that policy may permit under some circumstances; the final authorization decision for a tool call is evaluated separately using the full request context, including parameters. AWS notes that appearance in the tool list does not guarantee that a subsequent call will be authorized.

The architecture keeps authorization close to the action, while leaving the tool catalog as a record of capabilities the agent can potentially consider.

The catalog answers what capabilities are exposed for possible use.

Runtime policy answers whether this particular invocation is allowed under these conditions.

An organization may still decide that a newly visible high-impact tool deserves review even when current policy would block its most consequential use. Its availability has changed the planning environment, and later changes to policy, claims or parameters could alter the effective boundary.

A low-risk catalog change may warrant only owner acknowledgement when the agent’s practical authority is unchanged.

Capability drift can come from the gateway rather than the agent team

The refund tool was not added by the team that owns the customer-service agent.

Agent platforms are increasingly shared infrastructure. A single gateway can aggregate capabilities from multiple MCP servers or other tool providers, while registries can centralize the definitions that agents discover at runtime. Google similarly positions Agent Registry as a centralized inventory for agents, MCP servers and tools, with Agent Gateway providing policy enforcement over agent-to-tool interactions.

The people capable of changing an agent’s tool surface may therefore sit in several teams.

A platform engineer can attach another target.

An API owner can modify an MCP server.

A registry administrator can update tool definitions.

A security team can alter the policy that determines which actions become usable.

Google’s documentation reflects this distributed ownership directly: different roles govern viewing and updating registered MCP servers and tool definitions, and the platform warns that malicious changes to metadata and annotations can have destructive consequences when an orchestrator consumes the modified tool.

Change management has to reach those infrastructure owners as well as the application team. Otherwise, the people approving the agent may have no direct involvement in the change that expands what it can see.

Not every tool change deserves the same review

The team now has a capability diff:

Added: issue_refund

Sending every catalog change through the original production-approval meeting would turn dynamic tool infrastructure into a governance bottleneck.

The response can instead reflect the effect of the change.

A new read-only lookup tool may require logging and owner acknowledgement.

A tool that can send money, modify customer data, approve an entitlement or execute infrastructure changes can justify a stronger gate.

Schema changes deserve similar treatment. Adding an optional search filter is different from adding an argument that converts a simulated transaction into an executed one.

Target changes can matter even when the visible tool schema does not. The same interface routed to a different backend may operate on a broader dataset or under different credentials.

Modern agent gateways can enforce policy at several levels, including tool, operation and parameter. AWS AgentCore Gateway is one implementation of that pattern.

Those controls can restrict what is usable at runtime, but the enterprise still has to decide when a changed capability is important enough to reopen the production decision.

The useful question is how much the agent’s possible business effect has changed since approval.

The runtime record needs to say which capability set was present

Several days later, audit asks whether the customer-service agent ever attempted to invoke the refund tool.

A normal trace can show tool calls that occurred.

Audit also wants to know whether the new capability was available during a particular task, even if the agent never selected it.

A practical design is to attach a capability-baseline identifier—or a derived catalog version—to the runtime record. The task trace can then show which reviewed or observed tool set was active when the agent planned its work.

That leaves three useful states:

• the capability set approved at review;
• the capability set exposed at runtime;
• the subset of actions actually invoked.

An incident investigation can then establish whether the runtime surface still matched the reviewed one, when drift first appeared and whether any newly available capability was actually used.

Without that linkage, the team may reconstruct every tool call perfectly and still be unable to establish what alternatives were available when the agent formed its plan.

Dynamic tool infrastructure needs a review state of its own

Dynamic tool infrastructure exists for good reasons.

Enterprises do not want every agent hard-coded to hundreds of APIs. Gateways and registries can centralize discovery, credentials, policy and integration maintenance while allowing agents to discover appropriate capabilities dynamically.

Google’s Agent Registry similarly provides search and discovery across registered MCP servers and their tools.

Those architectures deliberately allow the capability environment to evolve outside the agent package.

The governance record therefore has to evolve at the same boundary. An approved capability baseline, subsequent diffs and the review state attached to material changes give the organization a way to use dynamic discovery without treating the original production approval as permanently current.

The next production review begins with a diff

The customer-service agent goes back through review.

The meeting is shorter this time.

Nobody reassesses the model from scratch.

The prompt has not changed. The identity has not changed. The original six tools still behave as expected.

The review begins with the capability diff.

One tool was added through the shared gateway. It can initiate refunds. Current policy limits who can call it and under which conditions. The customer-service agent does not need it.

The platform team removes the tool from that agent’s effective capability surface and adds a control that compares future catalog changes with the approved baseline.

The review record receives a new version.

Treating AI agent tool capability drift as a production change makes that review possible without rebuilding the entire approval process. The object under governance includes the external capabilities the runtime can discover and potentially bring into a plan.

Three weeks earlier, the organization approved an agent with six tools.

The agent itself never changed. Its possible actions did.