Fix/runtime policy feedback

[Mr-Lucky]

Summary

Require approval for remote script installer patterns and hidden network commands, relax OpenClaw workspace file path handling, and improve runtime policy feedback behavior with expanded tests and docs.

Type

• Bug fix
• New feature / detection rule
• Refactoring
• Documentation

Testing

• npm run build passes
• npm test passes (405 tests)
• Manually tested the change

Related Issues

Closes #

[github-actions]

AgentGuard PR Review

1. severity: high — src/action/index.ts hunk around the new if (!hasExplicitAllowlist) { return { decision: 'allow' ... } }

   • What can go wrong: any non-sensitive file path becomes automatically allowed when no filesystem allowlist is configured. This is a major policy regression from “deny/confirm by default” to “allow by default,” which can let agents read/write arbitrary files such as secrets, SSH material, or application configs that the new classifySensitiveFilePath() misses.
   • Concrete fix: keep the default behavior as confirm or deny for unlisted paths, and only allow paths that are explicitly allowlisted or covered by a narrowly scoped safe-path policy.

2. severity: high — src/adapters/openclaw-plugin.ts hunk adding isRuntimeAuthoritativeAllow(...)

   • What can go wrong: when runtime protection returns allow or warn, the plugin now bypasses AgentGuard fallback scanning for OpenClaw file reads/writes entirely. If the runtime policy is permissive or misclassifies a sensitive path, the fallback scanner never gets a chance to block or require approval.
   • Concrete fix: only short-circuit on a strict allow after verifying the action is non-sensitive, or require the fallback scanner to run for file operations unless the runtime decision is a validated block/deny for the same path.

3. severity: medium — src/action/detectors/exec.ts / src/runtime/evaluator.ts remote script execution changes

   • What can go wrong: analyzeRemoteScriptExecution() introduces SUSPICIOUS_REMOTE_SCRIPT_EXECUTION and MALICIOUS_REMOTE_SCRIPT_EXECUTION, but normalizeOssReason() maps both to REMOTE_CODE_EXECUTION and policyDecisionFor() only blocks on severity === 'critical'. This means many risky download-and-execute commands now downgrade to “require approval” even when the runtime policy previously blocked them, and the new host/TLD heuristics can miss common malicious cases (e.g. attacker-controlled HTTPS domains with no listed indicators).
   • Concrete fix: preserve the prior block semantics for clearly dangerous download-and-execute patterns, and add explicit tests/coverage for more shell variants and common URL forms before relaxing to approval.