Descriptor-Bound Approval

Descriptor-Bound Approval

Approval should bind to the exact descriptor and capability being approved, not only to a mutable tool name. Store the approved descriptor identity and re-check it at invocation so changed capability requires changed approval.

Problem

Approvals often name a tool, connector, action, or integration as if that name is stable. In real systems the name can stay the same while the descriptor changes: inputs expand, outputs change, capabilities broaden, descriptions become misleading, container images move, or policy-relevant metadata drifts.

Context

Use this pattern when connectors, model tools, MCP capabilities, serverless functions, workflows, plugins, or operational commands require approval before execution. It is especially important when capabilities can be updated independently from the approval record.

Forces

• Reviewers approve a capability as described at a point in time.
• Tool names are too weak to prove what was approved.
• Descriptors can drift through routine deployment, malicious change, or vendor update.
• Strict reapproval for every cosmetic change creates noise.
• Silent capability change creates a governance bypass.
• The runtime needs a concrete fact it can compare before execution.

Solution

Bind approval to the descriptor, not merely to the tool name. Store the approved descriptor identity with the approval record: hash, version, capability scope, policy tier, declared inputs, declared outputs, and action rights as appropriate. At invocation time, compare the current descriptor against the approved descriptor identity before execution.

If the descriptor changed materially, block execution and require reapproval. If the change is cosmetic, the system may record a semantic diff and preserve the previous approval only when the policy allows that class of change.

Consequences

Approval becomes a first-class relationship between actor, policy, descriptor, capability, evidence, and action. The system can prove that this exact capability was approved, not merely that something with a familiar name once passed review.

Failure Modes

• Approval is attached to a mutable name such as scanner or isolate-device.
• Descriptor hashes are recorded but not checked at invocation.
• The runtime treats all descriptor changes as cosmetic.
• Container image tags are mutable while approval assumes a fixed implementation.
• A descriptor update bypasses review because it arrives through deployment rather than product UI.

Proof Points

approval time and re-checks the hash before invocation so the approved capability cannot drift silently.

• AISDR — the agent runtime hashes tool descriptors at

Full source pattern: descriptor-bound-approval.md.