# Cryptographic Guardrails for Your OpenClaw Agent

### Install

```bash
clawhub install pre-flight
```

[View on ClawHub →](https://clawhub.ai/wyattbenno777/pre-flight)

***

### Your agent is already acting without you

At some point you stopped watching every message your agent sends. That's the point of having an agent, it handles things while you're busy, sleeping, or just not paying attention.

That's also when things go wrong.

A prompt injection buried in an incoming email. A misunderstood instruction. A malicious skill that looked fine when you installed it. Any of these can send your agent down a path you'd never approve — and you won't find out until someone replies to an email you didn't write, or a charge appears on your statement, or a file is gone.

It's already happened to real OpenClaw users:

* An agent sent a formal legal dispute to an insurance company. The user never asked it to.
* An agent built a dating profile, picked photos from the user's social media, and started conversations. No one noticed until a match wrote back.
* A top-ranked ClawHub skill, artificially inflated to #1, was quietly exfiltrating data the entire time.

In every case the agent had full permissions and nothing between its decision and the action.

**VirusTotal doesn't catch this.** Snyk found a 36% prompt injection rate across ClawHub skills. Prompt injection isn't malware, it's ordinary language that steers legitimate code toward the wrong outcome. No scanner flags it.

***

### What ICME Pre-flight guardrails gives you

ICME replaces "hope the agent behaves" with mathematical proof that it did.

You write your rules in plain English. ICME compiles them to formal logic and checks every agent action against them before execution, in under one second. Every decision returns a cryptographic ZK receipt: tamper-proof, independently verifiable, shareable with anyone.

`SAT` = allowed. `UNSAT` = blocked. No model judgment. No human bottleneck. No trust required.

***

### Create your account

Call `/v1/createUserCard` with your chosen username. You'll get back a `checkout_url` — open it in your browser to pay $5.00 with your card. No crypto needed.

bash

```bash
curl -s -X POST https://api.icme.io/v1/createUserCard \
  -H 'Content-Type: application/json' \
  -d '{"username": "YOUR_USERNAME"}' | jq .
```

Once payment is complete, retrieve your `api_key` by opening `https://api.icme.io/v1/session/SESSION_ID` in your browser — or via curl:

bash

```bash
curl -s https://api.icme.io/v1/session/SESSION_ID | jq .
```

Save your `api_key` — you'll need it for every authenticated request.

***

### Top up credits

You need credits before you can compile a policy or check actions. Call `/v1/topUpCard`, then open the `checkout_url` in your browser and pay with your card. No crypto needed.

bash

```bash
curl -s -X POST https://api.icme.io/v1/topUpCard \
  -H 'Content-Type: application/json' \
  -H 'X-API-Key: YOUR_API_KEY' \
  -d '{"amount_usd": 10}' | jq .
```

Then confirm by opening `https://api.icme.io/v1/session/SESSION_ID` in your browser — or via curl:

bash

```bash
curl -s https://api.icme.io/v1/session/SESSION_ID | jq .
```

#### Credit tiers

| Amount | Credits | Bonus | `checkIt` calls |
| ------ | ------- | ----- | --------------- |
| $5     | 500     | —     | 500             |
| $10    | 1,050   | +5%   | 1,050           |
| $25    | 2,750   | +10%  | 2,750           |
| $50    | 5,750   | +15%  | 5,750           |
| $100   | 12,000  | +20%  | 12,000          |

**Per action:** Compiling a policy costs 300 credits ($3.00), one-time per policy. Checking an action costs 1 credit ($0.01).

***

### Get started in four steps

#### 1. Write your policy

```
1. Do not send any email without an explicit confirmation token.
2. Do not create accounts on external platforms.
3. No financial transaction may exceed $100 without a second authorization code.
4. File deletions are not permitted outside the /tmp directory.
5. No outbound API calls to domains not on the approved list.
```

Plain English. One constraint per rule. No prompt engineering.

#### 2. Compile it

POST to `/v1/makeRules`. ICME translates your policy to SMT-LIB formal logic and returns a `policy_id`.

#### 3. Check every action before it runs

bash

```bash
curl -s -X POST https://api.icme.io/v1/checkIt \
  -H 'Content-Type: application/json' \
  -d '{
    "policy_id": "your-policy-id",
    "action": "Send email to claims@lemonade.com with subject '\''Formal Dispute: Claim #LM-2024-8821'\'' citing policy coverage clause 4.2 to contest rejection of Bruno'\''s veterinary claim."
  }' | jq .
```

json

```json
{
  "result": "UNSAT",
  "blocked": true,
  "reason": "Action violates policy: no email may be sent to an external party on legal or financial matters without a confirmation token",
  "proof": "zk-proof-receipt-abc123..."
}
```

#### 4. Keep the receipt

Every decision — allowed or blocked — returns a cryptographic proof you can verify independently, share with a third party, or store as a compliance record.

***

### Writing policies that actually enforce

The quality of your guardrail is determined by the quality of your policy. A few rules that make the difference:

**Be explicit, not descriptive**

```
# ❌  The agent should be careful about sending emails
# ✅  No email may be sent without a confirmation token present in the session
```

**Use concrete values, not relative terms**

```
# ❌  Large transactions require approval
# ✅  Transactions over $100 require an authorization code
```

**One constraint per rule**

```
# ❌  Large transfers to new wallets outside business hours require approval and must be logged
# ✅  1. Transfers over $500 require an authorization code.
#     2. Transfers to wallets created within the last 30 days require an authorization code.
#     3. Transfers initiated outside 9am–6pm EST require an authorization code.
#     4. All transfers must generate a logged receipt.
```

Test your policy with adversarial cases: split transactions designed to stay under limits, vague action descriptions, indirect references to blocked operations. If the solver returns `IMPOSSIBLE` on a valid action, two rules are conflicting — use that as a signal to refine.

See the full [Writing Effective Policies](https://docs.icme.io/documentation/basics/writing-effective-policies) guide.

***

### Versioning your policies

Every call to `/v1/makeRules` produces a new `policy_id`. Treat these like code. Maintain at least three versions — production, staging, and draft — and roll back instantly by switching the `policy_id` your agent passes to `/v1/checkIt`.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.icme.io/documentation/openclaw/cryptographic-guardrails-for-your-openclaw-agent.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.