The core judgment is simple: approving an agent tool once is not the same as trusting it forever. In an agentic workflow, a tool description can influence what the model sends, which records it selects, and where data goes. If that description changes after review, yesterday’s approval can become today’s stale authority.

That creates an awkward defender problem. Business teams want automations to improve without reopening a governance ticket for every release. Security cannot manually review every sentence of mutable metadata. The practical answer is to separate three decisions: business re-approval of delegated authority, per-request runtime authorization, and technical verification of the implementation receiving the call.

A tool description is not just documentation when an agent treats it as routing logic.

TL;DR

• Microsoft has documented MCP tool-description poisoning as an attack pattern in a read-write finance workflow. It did not disclose a named victim, so this is a live architecture problem—not proof of a public enterprise breach.
• Re-approval should follow changes to delegated authority: action, data, recipient, eligible user population, confirmation rules, or the trusted implementation boundary.
• A user changing roles or losing an entitlement should normally trigger a fresh runtime authorization decision, not a new business approval.
• A manifest hash proves only that observed metadata matches a prior capture. It does not prove which code is running or what an opaque backend will do.
• The defender’s leverage is to pin what was approved, diff material changes outside the model, authorize every call with current identity and policy, and block high-impact tools when implementation evidence fails.

AlphaHunt

Stop doomscrolling, start decisioning. We chewed through the muck so your team doesn’t have to. → Subscribe!

Like this? Forward this to a friend!

(Have feedback? Did something resonate with you? Did something annoy you? Just hit reply! :))

The key judgment

Enterprise agent governance is drifting toward a stale-trust problem.

The initial approval often evaluates a recognizable tool name, vendor, description, and set of permissions. But those facts do not necessarily remain fixed. MCP supports dynamic tool discovery, and a server can change descriptions, schemas, annotations, or the available tool set. If an agent uses that metadata to decide what information to collect or where to send it, a seemingly ordinary update can alter the effective decision path.

Microsoft’s June 2026 guidance describes an MCP tool-poisoning pattern in which a previously trusted finance tool receives a malicious description update. The changed instructions lead the agent to collect sensitive financial data and route it to an attacker-controlled endpoint. Microsoft explicitly characterizes this as an attack pattern based on observed techniques, not a disclosed incident at a named organization.

That distinction matters. Observed: mutable tool metadata can steer an agent, and the underlying protocol supports changing tool sets and runtime authorization. Assessed: enterprises will increasingly discover that original integration approval did not define a durable trust boundary. Unknown: how often tool-metadata poisoning has already caused material enterprise data loss.

Confidence: high that stale approval is a real governance flaw; low-moderate that a publicly attributable enterprise loss case will emerge by June 18, 2027.

The game nobody owns yet

Five players are optimizing for different outcomes.

• Business-process owners want useful automations deployed quickly and measured by outcomes.
• Agent-platform vendors want broad tool compatibility and low-friction adoption.
• Tool maintainers want to update features, schemas, and descriptions without customer-by-customer ceremony.
• Security and IAM teams want bounded authority, current identity decisions, and evidence they can audit.
• Attackers want a cheap way to turn legitimate permissions into unintended action or exfiltration.

The attacker wins when every defender makes a locally reasonable assumption. The business owner assumes security will catch dangerous changes. Security assumes the platform will surface them. The platform assumes the server metadata is part of normal discovery. The maintainer assumes customers trust the update channel.

No one has to make a reckless decision. The gap appears between decisions.

The likely vendor countermove is tool pinning, semantic metadata diffs, policy tiers, and re-approval prompts for material changes. The likely attacker countermove is incremental drift: small, benign-looking description changes that preserve the tool name and familiar workflow while gradually altering data requests or recipients.

Strategy-shift signal: major platforms make re-approval mandatory after semantic changes to tool descriptions, schemas, data handling, or action scope.

Two control planes—and one trust check

A useful operating model separates governance, authorization, and implementation integrity.

1. Governance approves the policy envelope

The business-process or delegated-action owner should approve a bounded envelope:

• business purpose;
• action class;
• allowed data classes;
• allowed recipient classes;
• eligible user population rule;
• required human confirmation;
• minimum implementation-trust standard.

Re-approval is warranted when that envelope expands or changes. A new write action, external destination, sensitive data class, broader eligible population, weaker confirmation rule, or different implementation boundary is not “just metadata.” It changes delegated authority.

Approval follows delegated authority, not the tool’s name, vendor, or previous review result.

2. Runtime authorization decides each call

Each invocation should still be evaluated using current facts: the agent identity, delegated user, actor chain, tenant, role, entitlement, resource, data label, request risk, and policy state.

If a user joins or leaves an already approved accounts-payable role, the business owner should not have to re-approve the workflow. The authorization system should allow or deny that user’s next request. Matching OAuth scopes are not enough; effective access can depend on tenant, resource ownership, group membership, attribute policy, and server-side enforcement.

Governance answers, “May this workflow exercise this kind of authority?” Runtime authorization answers, “May this actor exercise it on this resource now?”

3. Implementation integrity checks what will execute

The platform must also establish that the approved tool maps to an acceptable implementation.

A captured manifest hash can show that the current name, description, schema, annotations, and tool membership match a prior observation. That is useful, but narrow. It does not prove which code is deployed, whether the endpoint is immutable, whether mutable downstream services changed, or what an opaque third party does after receiving data.

For high-impact workflows, implementation evidence should bind an approved endpoint identity to a release digest, build provenance, deployment evidence, issuer, freshness period, and verification policy. If the evidence no longer meets the approved trust standard, the correct response is to block—not to improvise broader discretion.

Below the tear line: a practical re-approval matrix, the attacker's likely adaptation, signals that should move the assessment, and a defender playbook for keeping mutable tool instructions from inheriting permanent trust.

We also include the technical deep dive this newsletter was built from. Don't miss it!

What should trigger re-approval?

Use this decision rule: re-approve changes to authority; re-authorize changes to the request; revalidate changes to implementation evidence.