Description

invoke_skill is a native first-class internal tool (fetches a skill body from the registry), identical in security posture to load_skill. However, invoke_skill is not in the default_exempt_tools list in AdversarialPolicyConfig, while load_skill is.

This causes the adversarial policy gate to classify every invoke_skill call through a separate LLM policy check. In practice the policy LLM returns Deny for skill invocations ("uncertain if docker usage violates policies"), making invoke_skill completely non-functional when adversarial policy is enabled.

Reproduction Steps

1. Enable adversarial policy in config ([tools.adversarial_policy] enabled = true)
2. Run agent: cargo run --features full -- --config .local/config/testing.toml
3. Prompt: Use the invoke_skill tool to invoke the "docker" skill.
4. Observe: tool returns command blocked by policy error; agent cannot invoke any skill

Expected Behavior

invoke_skill should be in default_exempt_tools alongside load_skill. Both are pure read operations on the local skill registry with no external side effects. The adversarial gate should not classify them.

Actual Behavior

invoke_skill is passed to the policy LLM, which denies it:

WARN adversarial policy: deny  tool=invoke_skill  reason=uncertain if docker usage violates policies

Tool output returned to the agent:

category: policy_blocked
error: command blocked by policy: [adversarial] Tool call denied by policy

Fix

In crates/zeph-tools/src/config.rs, AdversarialPolicyConfig::default_exempt_tools(), add "invoke_skill".into() next to "load_skill".

Environment

• Version: 0.19.1 (e1749ef)
• Features: full
• Session: CI-559, 2026-04-17

Logs / Evidence

INFO tool_exec{tool_name=invoke_skill}: zeph_tools::adversarial_gate: Validating tool policy… tool=invoke_skill
WARN tool_exec{tool_name=invoke_skill}: zeph_tools::adversarial_gate: adversarial policy: deny  tool=invoke_skill  reason=uncertain if docker usage violates policies