Cryptographic Guardrails for Your OpenClaw Agent

Your OpenClaw agent is sending emails, executing trades, creating accounts, and modifying files — right now, while you're not watching. You have no proof it checked any rule before it acted.

Install

clawhub install pre-flight

View on ClawHub →

---

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

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

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

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

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

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 [email protected] with subject '\''Formal Dispute: Claim #LM-2024-8821'\'' citing policy coverage clause 4.2 to contest rejection of Bruno'\''s veterinary claim."
  }' | jq .

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 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.