Define generic opt-in policy for client runtime tools

[chubes4]

Problem

Agents API now has generic external runtime tool fulfillment primitives, and Data Machine has shipped scoped client-declared runtime tools. One policy detail remains product-shaped downstream: client/runtime tool declarations must be explicitly opted in before the model can see them.

Data Machine currently enforces this in ToolPolicyResolver::filterRuntimeToolsByPolicyOptIn(), combining allow_only, agent tool policy, and caller tool policy. That behavior is not Data Machine-specific. Any host accepting client-declared tools needs a generic rule so untrusted transport-provided tools are not exposed ambiently.

Desired outcome

Add a generic policy primitive for runtime/client tool opt-in.

Possible shape:

• Runtime/client declarations carry metadata such as runtime_tool, executor=client, or scope=run.
• WP_Agent_Tool_Policy or a dedicated helper can preserve/exclude runtime tools based on explicit allow policy.
• The policy composes with existing allow/deny/categories and mandatory-tool preservation.
• Hosts can still add product-specific permission gates.

Boundaries

Agents API should own the neutral safety rule for caller-provided runtime tools. Host products still own transport trust, permission checks, storage, fulfillment, and UX.

Acceptance criteria

• Runtime/client tools are excluded by default unless the caller/agent/policy explicitly allows them.
• The rule is reusable outside Data Machine.
• Data Machine can replace its local filterRuntimeToolsByPolicyOptIn() implementation with the upstream primitive.
• Tests cover allow mode, deny mode, allow_only, and non-runtime tools.

Related

• Generic external runtime tool lifecycle: Add generic external runtime tool fulfillment lifecycle #250
• Data Machine scoped runtime tools: Support scoped client-declared runtime tools Extra-Chill/data-machine#1485
• Data Machine fulfillment tracker: Implement client runtime tool callback fulfillment Extra-Chill/data-machine#2205