# Stop Watching Your Agents. Start Proving They're Right.

### The gap in agent observability

Agent observability today works like application monitoring: log what agents do, alert when something looks wrong, build dashboards to track patterns. This catches a lot. But for consequential agent decisions (payments, data sharing, compliance-gated actions) it has a structural limitation: **it detects failures after they happen.**

The agent already took the action, already sent the data, already executed the decision. The observability layer tells you about it later. Maybe seconds later, maybe hours.

Logs are also only as trustworthy as the infrastructure that produces them. They can be modified, selectively omitted, or lost. When multiple parties need to verify that a decision was compliant, everyone has to trust the platform that generated the trace.

Cryptographic proofs close both gaps. They verify correctness *before* execution, and they produce tamper-proof records that any party can check independently.

But proofs are only possible if the underlying decision is deterministic. That's where automated reasoning comes in.

***

### Why automated reasoning is the foundation

Most AI guardrails use a model to judge whether an action is safe. The problem: models are probabilistic. The same input might get a different answer tomorrow. You can log a probabilistic decision. You can monitor it. But you cannot prove it was correct, because the underlying judgment isn't sound in the formal sense.

Automated reasoning replaces model judgment with a mathematical solver. Policies compile into formal logic (SMT-LIB2). Agent actions are checked by an SMT solver that returns SAT (allowed) or UNSAT (blocked). Same policy plus same input equals same result, every time, on any machine.

That determinism is what makes the rest of the architecture possible:

1. **Automated reasoning** makes the decision deterministic and formally sound.
2. **Because it's deterministic**, you can wrap it in a zero-knowledge proof. The proof attests that the solver ran correctly on specific inputs and produced a specific output.
3. **Because there's a proof**, you don't need to monitor whether the decision was correct. The math already answered that.
4. **Because the proof is zero-knowledge**, anyone can verify it without seeing the policy, re-running the solver, or trusting the platform.

Remove automated reasoning from this chain and the whole thing collapses. You're back to an LLM judging actions, which means you're back to observability as your only safety net, because you can't prove a probabilistic system made the right call. You can only watch and hope.

***

### How proofs strengthen observability

ICME PreFlight produces a **cryptographic proof for every agent decision**. Not a log entry. Not a trace. A mathematical proof that a specific action was checked against a specific policy and the result was SAT or UNSAT.

This doesn't replace your monitoring stack. It adds a layer underneath that makes the decision record cryptographically secure.

|                          | Standard Observability           | + Cryptographic Proofs                    |
| ------------------------ | -------------------------------- | ----------------------------------------- |
| When failures are caught | After execution                  | Before execution (blocked at check time)  |
| Trust model              | Trust the logging infrastructure | Trust the math                            |
| Tamper resistance        | Logs can be modified             | Proofs are cryptographically tamper-proof |
| Third-party verification | Requires access to internal logs | Anyone can verify independently           |
| What you learn           | What happened                    | Why it was allowed to happen              |
| Audit cost               | Scales with log volume           | Proof cost is constant per decision       |

A monitoring system tells you "the agent performed Action X at 14:32." A cryptographic proof tells you "Action X was mathematically verified to satisfy the policy, here is the proof, and any machine can independently confirm this."

Your existing observability captures the execution. The proof captures the decision. Together they cover the full picture.

***

### Why the policy stays private

Traditional audit requires exposing your rules to anyone who needs to verify a decision. The monitoring system sees the full decision context: what rules were evaluated, what thresholds were applied, what exceptions were granted. This creates a tension between transparency (auditors need to see what happened) and confidentiality (the rules themselves may be proprietary or sensitive).

Zero-knowledge proofs resolve this tension.

**The auditor can verify every decision was correct without seeing the policy.** The proof demonstrates that a specific set of inputs was checked against a valid policy and the solver returned SAT or UNSAT. The auditor confirms the proof is valid. They never learn what the policy rules are, how many rules exist, or which rule any particular decision satisfied or violated.

This matters in practice for three reasons:

**Confidentiality.** An organization's policy rules can reveal its strategy, compliance regime, or risk posture. With ZK proofs, the verifier learns the result. Nothing about the rules.

**Multi-party audit without data sharing.** In regulated industries, multiple parties may need to verify that decisions were compliant: internal compliance, legal teams, external auditors, regulators. Each party can independently verify the proof without any party needing to share their internal rules or logs with the others.

**Policy evolution without audit disruption.** When the policy is updated, past proofs remain independently verifiable under the old policy. New proofs are verifiable under the new policy. The auditor doesn't need to understand the diff. They verify that each decision, under whichever policy was active at the time, produced a valid proof.

***

### What proofs cover vs. what monitoring covers

Proofs strengthen observability for the **decision layer**: was the action allowed? Did it satisfy the policy? Was the decision compliant?

Runtime behavior is still a monitoring problem. The proof says the action *passed the policy check*. Whether the downstream system actually behaved as expected is an execution question outside the formal system.

| Layer                                       | Proofs handle it?              | Monitoring needed? |
| ------------------------------------------- | ------------------------------ | ------------------ |
| Did the action satisfy the policy?          | Yes                            | No                 |
| Was the decision compliant?                 | Yes                            | No                 |
| Can the decision be audited later?          | Yes                            | No                 |
| Was the proof generated correctly?          | Yes (independently verifiable) | No                 |
| Did the downstream system behave correctly? | No                             | Yes                |
| Is the system meeting its SLA?              | No                             | Yes                |
| Did the API return errors at runtime?       | No                             | Yes                |

The decision layer is where audit risk concentrates and where traditional observability is weakest. Proofs make that layer cryptographically secure. The execution layer still benefits from the monitoring tools you already use.

***

### The proof-based audit trail

Every `checkIt` call produces a ZK proof receipt that records:

* What inputs were checked (the exact values evaluated by the solver)
* What policy was in effect (without revealing its contents)
* Whether the result was SAT or UNSAT
* A cryptographic proof that the check was performed correctly

These receipts are:

* **Tamper-proof.** You cannot forge, edit, or selectively omit a proof.
* **Independently verifiable.** Any machine can confirm the proof without re-running the pipeline.
* **Private.** The verifier learns the result without seeing the policy.
* **Permanent.** The receipt is valid regardless of whether the policy or platform changes later.

Store the `check_id` alongside every agent decision. If a regulator asks why a specific action was allowed, the proof answers the question without exposing your policy.


---

# 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/getting-started/stop-watching-your-agents.-start-proving-theyre-right..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.