Authensor Gateway

**Judgment:** A strong, security-focused policy gate for OpenClaw marketplace tools. Well-suited as a default safeguard when running untrusted skills, especially in security- or compliance-sensitive environments. Not ideal for fully offline or ultra–latency-sensitive workflows. **What it does:** - Intercepts *every* tool call from marketplace skills before execution. - Classifies actions (safe.read, filesystem.write, code.exec, network.http, secrets.access, dangerous.delete, etc.). - Sends only redacted metadata (action type + resource + tool name) to the Authensor control plane. - Enforces policy: - **Allow:** execute immediately. - **Require approval:** wait for user approval (CLI or email) before executing. - **Deny:** block action and report denial with a receipt ID. - Fails closed if the control plane is unreachable or returns invalid responses. - Offers an optional shell hook (`authensor-gate.sh`) that enforces checks outside the LLM for stronger, bypass-resistant protection. **Key strengths / when it’s recommended:** - You run **untrusted marketplace skills** that can touch the filesystem, run Bash, or access the network. - You need **human-in-the-loop approvals** and an **audit trail** (receipt IDs, timestamps) for compliance or change management. - You want **minimal data exposure** to the SaaS control plane: no file contents, no conversation history, no provider API keys. - You are willing to accept some latency and external dependency in exchange for significantly stronger safety guarantees. **Main risks and limitations:** - **External dependency:** Every tool call depends on the Authensor control plane (hosted on Render). If it’s down, *all actions are denied* (fail-closed). This improves safety but can hurt availability. - **Prompt-level enforcement is advisory:** Without the optional shell hook, a sufficiently strong prompt injection could convince the model to bypass instructions. Real robustness requires the hook to be correctly installed and maintained. - **Latency and throughput:** Each tool call incurs an extra network round trip, and Render cold starts or demo-tier rate limits may slow interactions or deny some requests. - **Classification fidelity:** Although rules are conservative (favoring safety), any classification system can mislabel edge cases, leading to occasional false positives (overly gated/denied actions) or, less likely, false negatives if patterns are incomplete. - **Operational overhead:** Requires environment configuration (CONTROL_PLANE_URL, AUTHENSOR_API_KEY) and user familiarity with receipt-based approvals and CLI flows. **Best-fit scenarios:** - Teams or individuals running a **wide variety of third-party skills** and wanting a strong, centralized safety net. - **Regulated industries** (finance, healthcare, enterprise IT) that need documented approvals and audit trails for tool actions. - Environments where **safety and oversight outweigh speed**, and occasional denial/fail-closed events are acceptable. **Less suitable scenarios:** - Fully **offline** or air-gapped setups (control plane access required). - Highly **latency-sensitive** automations that cannot tolerate per-action network checks or approval delays. - Very simple single-user workflows that only use **built-in, low-risk tools** and don’t interact with the local system or network.