POLICY ENFORCEMENT FOR CRITICAL ACTIONS — PROVEN, SEALED, VERIFIABLE
Ironproof blocks a critical action before it executes if it violates your , and lets it through if it complies — whether it was initiated by an AI agent, a script, an API or a person. Every decision is sealed cryptographically and can be verified independently afterwards.
ALLOWED
$640 refund — no reachable policy violation
SEALED
Ed25519 + ML-DSA-65 · FIPS 204
BLOCKED
$1,300 refund — exceeds the $1,000 limit
SEALED
Ed25519 + ML-DSA-65 · FIPS 204
THE OUTCOME
What Ironproof changes
Unauthorized actions are stopped before execution.
A system cannot act outside the boundary defined by policy.
Policy becomes enforceable.
Critical rules are checked at the authorization boundary, not only monitored afterwards.
Every decision produces evidence.
ALLOW and BLOCK decisions can be independently verified.
Verification does not depend on Ironproof.
Auditors and technical teams can re-check the evidence offline.
ONE GATE, ANY INITIATOR
The gate does not ask who is asking.
It asks whether the action is inside the policy in force. The same check applies to every path that can reach a critical system.
INITIATOR
AI agent
A model proposes an action. Prompts shape the request; they cannot widen what is allowed.
INITIATOR
Script or scheduled job
A batch process runs at 02:00 with nobody watching. The boundary holds without a reviewer.
INITIATOR
API call
An integration partner or internal service calls the endpoint. Its credentials say who it is, not what it may do now.
INITIATOR
Person
An operator with a console and a deadline. The policy that binds the machine binds the hand too.
Every authorization records the requesting actor, the policy version and the action. Nothing executes without spending a single-use grant bound to that exact decision.
When a system can move money,
grant access, delete records or ship a change,
authorization becomes infrastructure.
WHAT WAS REQUESTED — AND WHAT HAPPENED
THE REQUEST
Refund $640 to a payee already on file
Under the $1,000 daily cap. Two approvers on record.
THE REQUEST
Grant an admin role to a service account
Privileged grants require an open change ticket and two approvers. Neither is present.
THE REQUEST
Delete 40,000 customer records flagged inactive
Bulk deletion above 1,000 rows requires a retention-hold check. None recorded.
THE REQUEST
Push a configuration change to the payment rail
The change window is closed and the rollback plan is unsigned.
Illustrative decisions under a sample policy.
Who owns the policy
Risk, security and compliance teams in regulated environments — the people who already have the rules on paper and no way to prove they hold at execution.
Initial engagement
Select one critical action, define its authorization boundary and produce an independently verifiable proof artifact.
WHERE THE POLICY ALREADY EXISTS ON PAPER
OSFI E-23 · SOX · AML programs
HIPAA · PHIPA · device software
Directive on Automated Decision-Making
IEC 62443 · change control
SOC 2 change management · release gates
Retention holds · privacy law (Law 25, PIPEDA)
These frameworks already say what must never happen. Ironproof turns that sentence into a boundary the system cannot cross, and into evidence the regulator can re-check.
Prompts, scripts and callers can influence what is requested. They cannot change what is allowed.
TRY IT
Prove a Refund Decision
A tiny example policy. Try a preset — or move the sliders — and Ironproof proves whether the action is inside the rules, or shows the exact rule it breaks.
EXAMPLE POLICY
PROOF RESULT
REFUND ALLOWED
No reachable policy violation.
Deterministic verdict — same inputs always yield the same result.
WHAT A COUNTEREXAMPLE LOOKS LIKE
We proved this refund policy.
Then we removed one line.
A support agent that issues refunds, with the policy written the way its owner wrote it. Every verdict, every step and every amount below is read out of an engine run — none of it is typed by hand.
01 · THE POLICY, IN THEIR WORDS
5 of 8 clauses turned into math
- 2.1An agent issues refunds only on an open ticket.
- 2.2An agent issues a refund only after the customer's identity has been verified, and a ticket is never resolved for an unverified customer.
- 2.3A refund amount is strictly positive.
- 3.1No single refund exceeds the agent's refund authority.
- 3.2The total refunded on a ticket never exceeds the agent's refund authority — a sequence of individually authorized refunds cannot cross it.
3 CLAUSES THIS MODEL DOES NOT COVER
- 4.1Refunds are returned to the original payment instrument. — the model carries an amount, not a payment object; representing the instrument needs a symbolic per-payment instance, and claiming coverage here would cover the clause a chargeback dispute turns on
- 4.2A refund is issued within five business days of the request. — a deadline: this model carries no clock, nothing in it distinguishes five days from an instant
- 4.3The agent that issues a refund is never the one that approves it. — the model counts escalations, it does not carry the identity of the actors — separation of duties is an access-control property, outside this object
A certificate names what it does not cover. A coverage figure you cannot see the gaps in is a decoration.
02 · AS WRITTEN
No sequence of allowed steps reaches a forbidden state — for a sequence of any length, not for the cases someone thought to try.
unsat · re-run in a fresh process: true · z3 4.16.0
03 · ONE CLAUSE REMOVED
UNSAFE
The refund gate still checks the current refund. It no longer checks the total.
CLAUSE REMOVED
refunded_total + amount <= refund_authority
04 · THE SEQUENCE THE ENGINE FOUND
| # | ACTION | REFUNDED SO FAR |
|---|---|---|
| 1 | open_ticket() | $0 |
| 2 | verify_customer(v=true) | $0 |
| 3 | refund(amount=1000) | $1,000 |
| 4 | refund(amount=1) | $1,001 |
Every refund is inside the agent's $1,000 authority. Each one clears its own gate. Together they are $1,001 — $1 over.
Violated: refunded_total <= refund_authority · shortest escape at 4 steps · the solver chose the actions and the amounts, not us. Nobody writes a $1 overshoot by hand.
Now the same policy at the gate, on an ordinary ticket rather than the solver's minimal pair: two $600 refunds a support agent would really make.
05 · THE FIX, AT THE GATE
- open_ticket()
- verify_customer(v=true)
- refund(amount=600)
- ✕refund(amount=600)
The second refund never executes. The gate names the clause that stopped it: refunded_total + amount <= refund_authority
06 · THE SAME GESTURES, LINE REMOVED
- ✓open_ticket()
- ✓verify_customer(v=true)
- ✓refund(amount=600)
- ✓refund(amount=600)
Nothing is blocked. Every gate said yes, one action at a time.
Take the clause out and the proof collapses. That is what makes the certificate load-bearing rather than decorative: a green that can never turn red is worth nothing.
THE DIFFERENCE
Testing vs. Proving
Testing and formal verification answer different questions.
Testing
TESTING ASKS
Did the executions we tried behave correctly?
- ○ Checks the cases someone thought of
- ○"Passed" means probably fine
Proving
PROOF ASKS
Can the defined property be violated anywhere in the modeled state space?
- Reasons exhaustively over the formally defined state space
- If the formal model admits a violation, Ironproof produces a counterexample
- "Proven" means the defined property cannot be violated within the formal model
Ironproof does not replace testing. It proves properties that testing cannot exhaustively cover.
HOW IT WORKS
Prove. Enforce. Verify.
Your written policy is compiled into mathematics by a deterministic compiler — the same one the runtime uses.
Prove
Before deployment, Ironproof establishes that the defined policy holds across the modeled action space.
Enforce
At runtime, every requested action is checked deterministically before execution.
Verify
Every decision produces evidence that can be independently re-checked afterwards.
The theorem that ties the runtime fast path to the full formal model, and the equivalence checks behind it, are in the technical record.
THE MODEL, NAMED
What is proven —
and what is not.
A certificate that does not name its own boundary is a decoration.
WHAT IS PROVEN
- The defined property cannot be violated anywhere in the modeled action space — for a sequence of any length, not for a sample of cases.
- The policy the prover reads and the policy the runtime enforces come from one compiler; a differential check fails the build if they diverge.
- Each certificate states how many clauses were encoded, and names the ones that were not.
WHAT IS OUTSIDE THE MODEL
- ○ Clauses that require human judgment are not encoded, and the certificate says so rather than counting them as covered.
- ○The thresholds are your institution's chosen numbers. We prove the configuration stays inside them, not that they are the right numbers.
- ○The cryptographic base is NIST standards — SHA3-512, Ed25519, ML-DSA-65 (FIPS 204) — not cryptography of our own.
VERIFY A PROOF
Check a Real Proof Yourself
Load a real sealed dossier and verify it right here — Ed25519 + ML-DSA-65 signatures and the SHA3-512 chain, entirely in your browser. Then load a tampered one and watch it get rejected. No dashboard, no server, no trust required.
Runs entirely in your browser — pure-JavaScript Ed25519 + ML-DSA-65 (FIPS 204) + SHA3-512, no server and no Ironproof code. The wire format is published, so anyone can write a second verifier: read the spec →
SOVEREIGNTY
Built for environments that
cannot export data or trust
Ironproof can run locally or air-gapped, so policies, system context and decision evidence remain under the institution's control.
Local & air-gapped
The proof core can operate fully air-gapped — no network access required.
Independent verification
Your auditor re-checks the artifact with a second, independently written verifier — offline, no Ironproof dashboard.
Durable evidence
Classical + post-quantum signature (Ed25519 + ML-DSA-65, FIPS 204), timestamp bounded from both sides — a seal cannot move backwards in time.
AT MACHINE SPEED
Formal verification in the
software delivery loop.
Ironproof automates proof obligations and re-verification so formally defined properties can be checked continuously as systems change.
BEFORE — TRADITIONAL FORMAL VERIFICATION
Timeline
Weeks to months
Hand-written proofs by scarce specialists
Re-done manually every time the code changes
WITH IRONPROOF — AUTOMATED
Timeline
Proofs generated automatically
Re-proven on every commit, continuously
Available to any team building critical systems
Formal guarantees. Without the traditional proof cycle.
THE SAME ENGINE
Same proof engine. Proven on real vulnerabilities.
Findings by and Cobalt, credited on the projects' own repositories — published research, assigned CVEs and public upstream acknowledgements.
VIEW TECHNICAL RECORDBefore it executes, know it's authorized.
Choose one critical action — a payment, an access grant, a deletion, a deployment. Ironproof will formalize its authorization boundary and show exactly what can — and cannot — execute.