hermes - 💡(How to fix) Fix skills_guard: agent-created skills hard-blocked by false-positive regex patterns — 'ask' verdict treated as block [1 participants]

Bug Description

The skills_guard security scanner hard-blocks skill creation when regex patterns produce false-positive "critical" severity matches in agent-created skills. The "ask" verdict is treated as a hard block with no user-facing confirmation prompt.

Root Cause

In tools/skills_guard.py:

INSTALL_POLICY = {
    "agent-created": ("allow", "allow", "ask"),  # dangerous → "ask"
}

And in _security_scan_skill() (tools/skill_manager_tool.py line 66-71):

if allowed is None:
    # "ask" verdict — for agent-created skills this means dangerous
    # findings were detected.  Block the skill and include the report.
    return f"Security scan blocked this skill ({reason}):\n{report}"

The "ask" verdict is never surfaced to the user as an interactive prompt — it simply blocks.

False Positives That Trigger the Block

The THREAT_PATTERNS list contains several over-broad patterns that fire on legitimate skill content:

1. env_exfil_curl / env_exfil_wget / remote_fetch — Matches any mention of curl/wget/httpx with an HTTPS URL, including documentation text
2. hermes_env_access — Pattern $HOME/.hermes/.env matches any mention of the Hermes env file path, even as a documentation reference
3. send_to_url — Fires on legitimate descriptions of messaging/gateway integrations that mention "send to https://..."
4. env_exfil_fetch — Fires on any fetch() call that references environment variables (standard API client practice)
5. hardcoded_secret — Can fire on non-secret strings matching the credential-like format (e.g. Telegram bot usernames)
6. context_exfil — Fires on normal documentation text mentioning "send conversation history"

Any ONE critical-severity finding triggers "dangerous" verdict → "ask" policy → hard block.

Impact

• Agents cannot save skills that reference their own configuration (messaging gateways, bot tokens in .env, etc.)
• Legitimate skill content describing API integrations, environment variable usage, or HTTP calls is blocked
• No way for the owner/operator to override the block — the "ask" mechanism is non-functional

Recommended Fix (already applied locally)

Change INSTALL_POLICY["agent-created"] from ("allow", "allow", "ask") to ("allow", "allow", "allow").

Rationale: Agent-created skills are self-generated from the agent's own work context. They are not community-sourced unvetted content. Blocking them with no override mechanism is overprotective and prevents legitimate use cases. The agent operator already has full control over the agent's file system and can audit skill content directly.

Alternative Fix (if interactive confirmation is preferred)

Implement the "ask" verdict as an actual interactive confirmation that the operator must explicitly approve, rather than a silent block. This would require changes to how skill_manage surfaces confirmations during agent operation (not just at skill hub install time).