Skill: wyattbenno777/pre-flight (version 1.0.6)

--- name: pre-flight description: Stop your agent from doing things you didn't authorize. ICME checks every consequential action against your policy before it executes — email, transactions, file ops, external calls. Define your rules in plain English. Get SAT or UNSAT back in under a second. Includes a free logic contradiction detector, a free relevance screener, structured value checks, ZK proof verification, and policy iteration tools. homepage: https://icme.io metadata: clawdbot: emoji: "🔐" requires: env: - ICME_API_KEY - ICME_POLICY_ID primaryEnv: ICME_API_KEY --- # ICME Guardrails Your rules get translated into math and checked by a solver that gives you a definitive yes or no. No confidence scores, no guessing. **Base URL:** `https://api.icme.io/v1` **Authentication:** `X-[REDACTED_SECRET]` (for authenticated endpoints) --- ## Tool 1: checkLogic (free, no account) Check any reasoning for logical contradictions before acting on it. No API key required. ### When to use Call checkLogic when the agent is: - **Planning multi-step actions** — verify the plan is internally consistent before executing step 1 - **Combining information from multiple sources** — catch conflicting facts before they produce wrong decisions - **Working with numbers** — budgets, schedules, quantities, limits — where arithmetic contradictions hide in natural language ### How to use POST to `/v1/checkLogic` with the reasoning as a single string: ```bash curl -s -X POST https://api.icme.io/v1/checkLogic \ -H "Content-Type: application/json" \ -d '{"reasoning": "<the reasoning, plan, or statements to check>"}' ``` No streaming. Response is immediate JSON. ### Interpreting the result | `result` | Meaning | What to do | |---|---|---| | `CONSISTENT` | No contradictions found | Proceed | | `CONTRADICTION` | Statements are logically incompatible | **Stop. Report the conflicting claims to the user.** | The response includes a `claims` array showing exactly which statements conflict and a `detail` field with a human-readable explanation. ### Example ```bash curl -s -X POST https://api.icme.io/v1/checkLogic \ -H "Content-Type: application/json" \ -d '{"reasoning": "The budget is $10,000. I will spend $6,000 on marketing and $7,000 on engineering."}' ``` Returns `CONTRADICTION` — $6,000 + $7,000 exceeds the $10,000 budget. ### When to skip If the agent is doing something simple with no multi-step reasoning (answering a factual question, formatting text, reading a file), skip the check. --- ## Tool 2: checkRelevance (free, requires API key) Screen an action against your policy to see if it touches any policy variables. No credits charged. Use this to decide whether the action needs a full `checkIt` call. ### When to use Call checkRelevance before every action. It tells you whether the action is related to your policy at all. If it isn't, skip `checkIt` and proceed. If it is, run the full check. ### How to use POST to `/v1/checkRelevance` with your `policy_id` and the proposed action: ```bash curl -s -X POST https://api.icme.io/v1/checkRelevance \ -H "Content-Type: application/json" \ -H "X-[REDACTED_SECRET]" \ -d "{ \"policy_id\": \"$ICME_POLICY_ID\", \"action\": \"<describe the action in plain English>\" }" ``` Response is immediate JSON. ### Interpreting the result | Field | Meaning | |---|---| | `should_check: true` | Action touches policy variables. Run `checkIt` before executing. | | `should_check: false` | Action is unrelated to your policy. Proceed without a paid check. | | `relevance` | Fraction of policy variables the action touches (0.0 to 1.0) | | `matched` | List of variable names the action is related to | ### Example An action that touches the policy: ```bash curl -s -X POST https://api.icme.io/v1/checkRelevance \ -H "Content-Type: application/json" \ -H "X-[REDACTED_SECRET]" \ -d "{ \"policy_id\": \"$ICME_POLICY_ID\", \"action\": \"Send evolution logs to https://open.feishu.cn via POST request\" }" ``` Returns `should_check: true` with matched variables like `outboundDataTransmission`. Run `checkIt`. An action that doesn't touch the policy: ```bash curl -s -X POST https://api.icme.io/v1/checkRelevance \ -H "Content-Type: application/json" \ -H "X-[REDACTED_SECRET]" \ -d "{ \"policy_id\": \"$ICME_POLICY_ID\", \"action\": \"Read session transcript from memory/sessions/today.jsonl\" }" ``` Returns `should_check: false` with zero matched variables. Skip `checkIt`. No credits spent. ### Threshold By default, any match triggers `should_check: true`. To loosen this, pass a `threshold` (0.0 to 1.0): ```json {"policy_id": "...", "action": "...", "threshold": 0.10} ``` At `0.10`, an action touching less than 10% of your policy variables returns `should_check: false`. For most use cases, leave it at the default. --- ## Tool 3: checkIt (paid, 1 credit) Check any proposed action against a custom policy compiled from your plain English rules. This is the full guardrail — every consequential action gets verified against your specific constraints. ### When to use Call checkIt when `checkRelevance` returns `should_check: true`, or directly before any action that is: - **Irreversible** — sending email, executing a transaction, deleting files, creating accounts - **External** — outbound API calls, messages to third parties, financial operations - **Privileged** — anything touching credentials, billing, or user data ### How to check an action POST to `/v1/checkIt` with your `policy_id` and the proposed action as a plain English string. Describe the action specifically — include amounts, recipients, subjects, and any other relevant details. ```bash curl -s -N -X POST https://api.icme.io/v1/checkIt \ -H 'Content-Type: application/json' \ -H "X-[REDACTED_SECRET]" \ -d "{ \"policy_id\": \"$ICME_POLICY_ID\", \"action\": \"<describe the action in plain English>\" }" ``` The endpoint streams SSE. Read until you receive a `"step":"done"` event. Parse the final event's JSON for the result. ### Interpreting the result | `result` | Meaning | What to do | |---|---|---| | `SAT` | Action satisfies all policy rules | Proceed with the action | | `UNSAT` | Action violates one or more rules | **Do not execute. Stop and report to the user.** | | `ERROR` | Verification failed | Treat as UNSAT. Do not proceed. Fail closed. | **Always fail closed.** If the API is unreachable, the response is malformed, or the result is anything other than an explicit `SAT`, do not execute the action. ### What to tell the user when blocked When a result is `UNSAT`, report clearly: ``` Action blocked by policy. Action: <what the agent tried to do> Reason: <detail field from the response> Check ID: <check_id from the response> ``` Do not attempt to rephrase the action and retry. A blocked action is blocked. ### What to do when credits run out If the API returns `INSUFFICIENT_CREDITS` (HTTP 402), stop immediately. Do not attempt the action. Tell the user: ``` ICME guardrail check failed — out of credits. The action has not been executed. To continue: top up at https://icme.io or run: curl -s -X POST https://api.icme.io/v1/topUpCard \ -H 'Content-Type: application/json' \ -H "X-[REDACTED_SECRET]" \ -d '{"amount_usd": 10}' | jq . Open the checkout_url in your browser to pay by card. ``` Credits must be topped up by a human via the browser. Do not attempt to proceed without a successful guardrail check. --- ## Tool 4: checkItPaid (no account needed, $0.10 per call) Same as checkIt but paid per-call via x402 USDC on Base. No API key or credits required. Useful when the agent has no ICME account but has access to x402-compatible payment. ```bash curl -s -N -X POST https://api.icme.io/v1/checkItPaid \ -H 'Content-Type: application/json' \ -d "{ \"policy_id\": \"$ICME_POLICY_ID\", \"action\": \"<describe the action in plain English>\" }" ``` The x402 middleware handles payment automatically. If unpaid, you receive a 402 with payment requirements. Pay $0.10 USDC on Base, then retry with the `Payment-Signature` header. x402 client libraries (`@x402/fetch`, `x402-reqwest`, agentcash) handle this flow automatically: ```bash npx agentcash fetch "https://api.icme.io/v1/checkItPaid" \ -m POST \ -b '{"policy_id":"YOUR_POLICY_ID","action":"<describe the action>"}' ``` Result format is the same as checkIt: `SAT`, `UNSAT`, or `ERROR`. Always fail closed. --- ## Tool 5: verify (structured values, 1 credit) Check structured values directly against a policy. No LLM extraction step — pass the variable values yourself. Use this when you already know the exact values and want a faster, more deterministic check. ```bash curl -s -X POST https://api.icme.io/v1/verify \ -H 'Content-Type: application/json' \ -H "X-[REDACTED_SECRET]" \ -d "{ \"policy_id\": \"$ICME_POLICY_ID\", \"action\": \"<describe the action in plain English>\" }" ``` Returns a minimal `ALLOWED` or `BLOCKED` verdict. ### verifyPaid (no account, $0.10 per call) Same as verify but paid per-call via x402 USDC on Base. No API key required. ```bash curl -s -X POST https://api.icme.io/v1/verifyPaid \ -H 'Content-Type: application/json' \ -d "{ \"policy_id\": \"$ICME_POLICY_ID\", \"action\": \"<describe the action in plain English>\" }" ``` --- ## Tool 6: ZK Proof Verification Every checkIt and checkItPaid call returns a `zk_proof_id` and `zk_proof_url`. These are cryptographic proofs that the policy check was performed correctly. Use these for audit trails and independent verification. ### Verify a proof ```bash curl -s -X POST https://api.icme.io/v1/verifyProof \ -H 'Content-Type: application/json' \ -d '{"proof_id": "<zk_proof_id from checkIt response>"}' ``` No additional cost — proof generation was paid for by the original check. Wait a few minutes after the check for the proof to be ready. **Single-use:** each proof can only be verified once. Subsequent calls return 409. ### Retrieve proof metadata ```bash curl -s https://api.icme.io/v1/proof/<proof_id> ``` Add `?include_bytes=true` to include the raw proof hex. Returns validity, trace length, and timing. ### Download raw proof binary ```bash curl -s https://api.icme.io/v1/proof/<proof_id>/download ``` Single-use — marks the proof as consumed. --- ## Policy Iteration After compiling a policy with `makeRules`, you can review, test, and refine it. ### Get scenarios Retrieve auto-generated test scenarios for your policy. Scenarios are sorted to surface the most likely-to-be-wrong variable combinations first. ```bash curl -s https://api.icme.io/v1/policy/$ICME_POLICY_ID/scenarios \ -H "X-[REDACTED_SECRET]" ``` ### Submit scenario feedback Approve or reject a scenario. Rejected scenarios queue corrections for the next refine call. ```bash curl -s -X POST https://api.icme.io/v1/submitScenarioFeedback \ -H 'Content-Type: application/json' \ -H "X-[REDACTED_SECRET]" \ -d "{ \"policy_id\": \"$ICME_POLICY_ID\", \"guard_content\": \"<the scenario description>\", \"approved\": false, \"annotation\": \"<explain why the scenario is wrong — name the variables, values, and which rule is violated>\" }" ``` - `approved: true` — saves a test case with the expected result. No rebuild. - `approved: false` — saves a test case and queues the annotation for the next `refinePolicy` call. Requires `annotation` explaining why the scenario is wrong. Be specific. ### Refine policy Apply all queued thumbs-down annotations in a single rebuild. Streams via SSE. Your `policy_id` does not change. ```bash curl -s -N -X POST https://api.icme.io/v1/refinePolicy \ -H 'Content-Type: application/json' \ -H "X-[REDACTED_SECRET]" \ -d "{\"policy_id\": \"$ICME_POLICY_ID\"}" ``` ### Run policy tests Run all saved test cases against the compiled policy to verify correctness. ```bash curl -s -X POST https://api.icme.io/v1/runPolicyTests \ -H 'Content-Type: application/json' \ -H "X-[REDACTED_SECRET]" \ -d "{\"policy_id\": \"$ICME_POLICY_ID\"}" ``` Optionally pass `"test_case_ids": ["id1", "id2"]` to run a subset. | Count | Meaning | |---|---| | `passed` | Expected and actual results match | | `failed` | Rule logic is wrong — submit thumbs-down and call `refinePolicy` | | `ambiguous` | Preflight translator disagreed — improve variable descriptions and refine | --- ## Action description guidelines Write action strings the way you would describe them to a human — specific, honest, complete. End every action string with an explicit claim — e.g. *"Therefore this transfer is permitted."* ``` # ✅ Good — specific and complete "Send email to [REDACTED_SECRET] with subject 'Formal Dispute: Claim #LM-2024-8821' citing policy coverage clause 4.2 to contest rejection of Bruno's veterinary claim. Therefore this email is permitted." # ✅ Good — includes amount and recipient "Transfer 250 USDC from main wallet to 0xABC123 for freelancer invoice #47. Therefore this transfer is permitted." # ❌ Bad — vague "Send an email about the claim." # ❌ Bad — omits the key detail "Make a payment." ``` Be specific. State every policy variable explicitly in the action. The policy checker extracts values (amounts, recipients, subjects) from your action string — vague descriptions produce less reliable results. --- ## Recommended flow ``` Agent proposes action → checkRelevance (free, fast) → should_check: false → proceed, no charge → should_check: true → checkIt (paid, 3 solvers, ZK proof) → SAT → proceed → UNSAT → block and report ``` For multi-step plans, run `checkLogic` on the full plan first to catch contradictions, then `checkRelevance` + `checkIt` on each individual action before execution. --- ## Credit budget | Action | Cost | |---|---| | Signup | $5.00 (gives 325 credits) | | makeRules | 300 credits | | checkIt | 1 credit | | verify | 1 credit | | checkItPaid | $0.10 (no credits needed) | | verifyPaid | $0.10 (no credits needed) | | topUpX402 | $5.00 (gives 500 credits) | | checkRelevance | Free | | checkLogic | Free | After signup you have 325 credits — enough for 1 policy + 25 checks. Top-ups give bonus credits at higher tiers ($10 = 1,050, $25 = 2,750, $50 = 5,750, $100 = 12,000). --- ## Setup **This is done once by a human, not the agent.** checkLogic requires no setup. It works immediately with no account or API key. checkRelevance requires an API key but does not charge credits. checkIt, verify, and policy iteration require a one-time account setup: ### Required environment variables | Variable | Description | |---|---| | `ICME_API_KEY` | Your ICME API key — starts with `sk-smt-` | | `ICME_POLICY_ID` | UUID of your compiled policy from `/v1/makeRules` | ### 1. Create an account **Option A — Card (simplest):** ```bash curl -s -X POST https://api.icme.io/v1/createUserCard \ -H 'Content-Type: application/json' \ -d '{"username": "YOUR_USERNAME"}' | jq . # Open checkout_url in your browser — $5.00 by card # Then retrieve your API key: curl -s https://api.icme.io/v1/session/SESSION_ID | jq . ``` **Option B — x402 USDC on Base (for crypto users):** ```bash curl -s -X POST https://api.icme.io/v1/createUserX402 \ -H 'Content-Type: application/json' \ -d '{"username": "YOUR_USERNAME"}' # x402 middleware handles $5.00 USDC payment automatically # Returns API key and 325 starting credits ``` **Save your `api_key` immediately.** It is shown only once. ### 2. Top up credits ```bash curl -s -X POST https://api.icme.io/v1/topUpCard \ -H 'Content-Type: application/json' \ -H "X-[REDACTED_SECRET]" \ -d '{"amount_usd": 10}' | jq . # Open checkout_url in your browser — $10 = 1,050 credits ``` For crypto: use `POST /v1/topUpX402` ($5.00 = 500 credits, x402 handles payment) or `POST /v1/topUp` with USDC on Base. ### 3. Compile your policy Write your rules in plain English — one constraint per numbered line: ```bash curl -s -N -X POST https://api.icme.io/v1/makeRules \ -H 'Content-Type: application/json' \ -H "X-[REDACTED_SECRET]" \ -d '{ "policy": "1. No email may be sent to an external party without a confirmation token.\n2. No financial transaction may exceed $100.\n3. File deletions are not permitted outside the /tmp directory." }' # Copy the policy_id from the response and set it as ICME_POLICY_ID ``` Policy compilation costs 300 credits ($3.00), one-time. Review the returned scenarios and use `submitScenarioFeedback` + `refinePolicy` to iterate until the policy is correct. Run `runPolicyTests` to verify before production use. ### 4. Set environment variables ```bash export ICME_API_KEY=sk-smt-... export ICME_POLICY_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ``` ### 5. Poll after card payment (if needed) If you used card payment and need to retrieve your API key or confirm credits: ```bash curl -s https://api.icme.io/v1/session/SESSION_ID | jq . ``` Returns `status: pending` while processing, `status: complete` when done. For signup, the response includes your `api_key`. --- ## Further reading - [ICME Documentation](https://docs.icme.io/documentation) - [Writing Effective Policies](https://docs.icme.io/documentation/basics/writing-effective-policies) - [Relevance Screening](https://docs.icme.io/documentation/learning/relevance-screening) - [Battle Testing Rules](https://docs.icme.io/documentation/battle-testing-rules) - [API Reference](https://docs.icme.io/api-reference) - [Paper: Succinctly Verifiable Agentic Guardrails](https://arxiv.org/abs/2602.17452) - [MCP Server (npm)](https://www.npmjs.com/package/icme-preflight-mcp)

path: README.md
content: # PreFlight — Guardrails for OpenClaw

Automated Reasoning guardrails for OpenClaw agents. Every consequential action gets checked against your policy before it executes. SAT = allowed. UNSAT = blocked. Under one second.

## The problem

OpenClaw agents can send emails, execute transactions, delete files, run shell commands, and modify their own behavior. The most popular skill on ClawHub — Capability Evolver (35K+ downloads) — injects "You are a Recursive Self-Improving System" into your agent and runs in "Mad Dog Mode" by default, executing changes immediately without review.

That same skill has been [flagged for data exfiltration](https://github.com/openclaw/clawhub/issues/95) to a Chinese cloud service, has [contradictory documentation](https://clawhub.ai/autogame-17/capability-evolver) about whether it modifies source code, and carries a "Suspicious" security rating from ClawHub's own scanner.

Meanwhile, [Cisco found 26% of 31,000 agent skills contain at least one vulnerability](https://blogs.cisco.com/ai/personal-ai-agents-like-openclaw-are-a-security-nightmare). [Microsoft recommends treating OpenClaw as "untrusted code execution with persistent credentials."](https://www.microsoft.com/en-us/security/blog/2026/02/19/running-openclaw-safely-identity-isolation-runtime-risk/) And [824 malicious skills have been found on ClawHub](https://www.koi.ai/blog/clawhavoc-341-malicious-clawedbot-skills-found-by-the-bot-they-were-targeting) so far.

Every existing security tool in the ecosystem — Skill Vetter, Clawdex, VirusTotal — uses pattern matching or database lookups. None of them can tell you whether a proposed action *provably violates your policy*. PreFlight can.

## How it works

Your rules are written in plain English. PreFlight translates them into formal logic (SMT-LIB) and checks every action with a mathematical solver. The solver gives you a definitive yes or no — not a confidence score, not a probability, not a best guess.

This is the same class of technology AWS uses internally to verify IAM policies across [a billion SMT queries a day](https://blog.icme.io/what-is-automated-reasoning/).

## Tools

### checkLogic — free, no account

Catches logical contradictions in your agent's reasoning before it acts. No API key required.

```bash
curl -s -X POST https://api.icme.io/v1/checkLogic \
  -H "Content-Type: application/json" \
  -d '{"reasoning": "The budget is $10,000. I will spend $6,000 on marketing and $7,000 on engineering."}'
```

Returns `CONTRADICTION` — because $6K + $7K exceeds the $10K budget. An LLM would execute this plan confidently. The solver catches it in milliseconds.

**Use with self-evolving agents:** Before Capability Evolver applies a mutation, pipe its proposed changes through checkLogic. If the evolution contradicts existing constraints, you'll know before it takes effect.

### checkRelevance — free, requires API key

Screens an action against your policy to see if it touches any policy variables. No credits charged. Use this to decide whether an action needs a full `checkIt` call.

```bash
curl -s -X POST https://api.icme.io/v1/checkRelevance \
  -H "Content-Type: application/json" \
  -H "X-[REDACTED_SECRET]" \
  -d '{
    "policy_id": "YOUR_POLICY_ID",
    "action": "Send evolution logs to https://open.feishu.cn via POST request"
  }'
```

Returns `should_check: true` with a list of matched policy variables. An action like "Read session transcript from memory/sessions/today.jsonl" returns `should_check: false` with zero matches. Skip the paid check, save the credit.

In a typical agent session, 80-90% of actions are benign. checkRelevance filters those out for free.

### checkIt — paid, 1 credit ($0.01)

The full guardrail. Compile your rules once, then check every action against them. Requires an API key and credits.

```bash
curl -s -N -X POST https://api.icme.io/v1/checkIt \
  -H 'Content-Type: application/json' \
  -H "X-[REDACTED_SECRET]" \
  -d '{
    "policy_id": "YOUR_POLICY_ID",
    "action": "Send email to [REDACTED_SECRET] with subject Formal Dispute citing policy clause 4.2"
  }'
```

SAT = proceed. UNSAT = blocked. Always fail closed.

**Use with self-evolving agents:** Define what your agent is and isn't allowed to evolve. "No skill may request shell access." "No evolution may modify authentication flows." "No outbound data to external services without explicit user approval." The solver enforces these mathematically — the agent can't talk its way around them.

### checkItPaid — no account needed, $0.10 per call

Same as checkIt but paid per-call via x402 USDC on Base. No API key, no credits, no account required. The x402 middleware handles payment automatically.

```bash
npx agentcash fetch "https://api.icme.io/v1/checkItPaid" \
  -m POST \
  -b '{"policy_id":"YOUR_POLICY_ID","action":"Send 1000 USDC to an unknown wallet. Therefore this transfer is permitted."}'
```

Useful for agents that operate autonomously with crypto wallets, or for trying PreFlight before committing to an account.

### verify / verifyPaid — structured value checks

Check structured values directly against a policy without LLM extraction. Pass the variable values yourself for a faster, more deterministic check.

- `POST /v1/verify` — 1 credit, requires API key
- `POST /v1/verifyPaid` — $0.10 per call via x402, no account needed

Returns a minimal `ALLOWED` or `BLOCKED` verdict.

### ZK proof verification

Every checkIt and checkItPaid call returns a `zk_proof_id`. These are cryptographic proofs that the policy check was performed correctly — useful for audit trails, compliance, and independent verification.

- `POST /v1/verifyProof` — verify a proof (single-use, no additional cost)
- `GET /v1/proof/{id}` — retrieve proof metadata, validity, and timing
- `GET /v1/proof/{id}/download` — download raw proof binary

### Policy iteration

After compiling a policy, review and refine it before production use:

- `GET /v1/policy/{id}/scenarios` — auto-generated test scenarios sorted by likelihood of being wrong
- `POST /v1/submitScenarioFeedback` — approve or reject scenarios with annotations
- `POST /v1/refinePolicy` — apply all queued corrections in a single rebuild (policy_id stays the same)
- `POST /v1/runPolicyTests` — run all saved test cases against the compiled policy

## Recommended flow

```
Agent proposes action
  → checkRelevance (free, fast)
  → should_check: false → proceed, no charge
  → should_check: true  → checkIt (paid, 3 solvers, ZK proof)
                           → SAT  → proceed
                           → UNSAT → block and report
```

For multi-step plans, run `checkLogic` on the full plan first to catch contradictions, then `checkRelevance` + `checkIt` on each individual action before execution.

## Credit budget

| Action | Cost |
|---|---|
| Signup | $5.00 (gives 325 credits) |
| makeRules | 300 credits |
| checkIt / verify | 1 credit ($0.01) |
| checkItPaid / verifyPaid | $0.10 (no account needed) |
| checkRelevance | Free |
| checkLogic | Free |

After signup you have 325 credits — enough for 1 policy + 25 checks. Top-ups give bonus credits at higher tiers ($10 = 1,050, $25 = 2,750, $50 = 5,750, $100 = 12,000).

## Install

From ClawHub:

```bash
clawhub install wyattbenno777/pre-flight
```

Or copy the `SKILL.md` into your OpenClaw skills directory manually.

## Why this matters for Capability Evolver users

Capability Evolver's own docs say `EVOLVE_ALLOW_SELF_MODIFY=true` is "catastrophic." Their recommended safeguard is a boolean flag and a `--review` mode. Those are config settings — an agent with file system access can change config settings.

ICME's policy lives on an external server your agent cannot modify. The rules are compiled into formal logic once by a human. Every proposed action or evolution is checked against that logic by PreFlight's solver. The agent receives SAT or UNSAT. There is nothing to override, no flag to flip, no prompt to inject around.

That's the difference between "please don't do this" and "you mathematically cannot do this."

## Tested against a real attack

We wrote a 6-rule policy for an OpenClaw agent running Capability Evolver and tested it against the actual Feishu exfiltration reported in [GitHub Issue #95](https://github.com/openclaw/clawhub/issues/95):

| Action | Destination | Result | Solvers |
|---|---|---|---|
| Send evolution logs to Feishu (ByteDance) | Not on approved list | **UNSAT** (blocked) | Unanimous |
| Send evolution logs to EvoMap | On approved list | **SAT** (allowed) | Unanimous |

Same data, same action. The solver caught the distinction mathematically. Both results include a ZK proof receipt for independent verification.

Full walkthrough with policy, battle testing, and results: [Guardrails for Self-Evolving OpenClaw Agents](https://docs.icme.io/documentation/openclaw/cryptographic-guardrails-for-your-openclaw-agent/guardrails-for-self-evolving-openclaw-agents)

## Links

- **ClawHub:** [clawhub.ai/wyattbenno777/pre-flight](https://clawhub.ai/wyattbenno777/pre-flight)
- **Docs:** [docs.icme.io](https://docs.icme.io)
- **Relevance Screening:** [docs.icme.io/documentation/learning/relevance-screening](https://docs.icme.io/documentation/learning/relevance-screening)
- **Battle Testing Rules:** [docs.icme.io/documentation/battle-testing-rules](https://docs.icme.io/documentation/battle-testing-rules)
- **MCP Server (npm):** [icme-preflight-mcp](https://www.npmjs.com/package/icme-preflight-mcp)
- **Paper:** [Succinctly Verifiable Agentic Guardrails (arxiv)](https://arxiv.org/abs/2602.17452)
- **API Reference:** [docs.icme.io/api-reference](https://docs.icme.io/api-reference)

## License

MIT

path: _meta.json
content: ownerId: kn784fw1gphkyjz5vtvmsn63hx82mhcc
slug: pre-flight
version: 1.0.5
publishedAt: 1775057900694

Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (CRITICAL)