FR

AUTHORIZATION BEFORE EXECUTION

If it isn't authorized, it never executes.

Ironproof checks every critical action before execution, not after.

START A PILOT WATCH IT DECIDE

WHAT IRONPROOF IS

A checkpoint between your automation and the actions it can’t undo.

AI agents, APIs and scripts can already move money, grant access, delete records and ship changes on their own. Ironproof sits in front of those actions and checks each one against your rules before it runs.

Allowedit runs.

Not allowedit never runs.

  1. 01

    Checked before, not logged after

    Every action waits at the gate until it clears your policy. No language model decides: the same request under the same policy always gets the same answer.

  2. 02

    Proven, not tested

    We don’t test your rules, we prove them. You leave with the exact case that breaks them, or the proof that no such case exists.

  3. 03

    Sealed, so anyone can check

    Every decision, allowed or blocked, is sealed. Your auditor re-checks it on their own machine, without us.

WATCH IT DECIDE

Four kinds of action. One gate.

Pick what the agent is trying to do. Every request is checked against the policy before it runs — and every decision, allow or block, leaves a sealed record.

INITIATOR AI agent · treasury-ops

REQUESTED ACTION

Internal transfer of $30,000, after a $35,000 wire earlier today

POLICY CHECKS

  • Transfer under its own cap of $50,000
  • Wires + internal transfers today under the combined cap of $60,000
  • Destination account owned by the same client

Blocked. It never executes.

A rule fails. The action does not run, and the refusal is sealed with the reason.

WHAT THE SEALED RECORD CARRIES

  1. 01The exact action requested, and by whom
  2. 02The policy version in force
  3. 03The verdict and the rule that decided it
  4. 04Two signatures (Ed25519 + ML-DSA-65), re-checkable offline
CHECK A REAL SEALED RECORD

Illustrative decisions under a sample policy.

WHY A LOGIN IS NOT ENOUGH

Logged in is not the same as allowed.

Your agent already has credentials. That settles who it is — not whether this specific action, right now, is inside your policy.

01 · AUTHENTICATION — ALREADY SOLVED

Who is asking? Keys, tokens, SSO, service accounts. An agent running in production has already passed it.

02 · AUTHORIZATION — WHERE IRONPROOF SITS

Should this action execute? Amount, cumulative totals, approvals, time windows, holds — checked before the action runs, every time.

An agent with valid credentials and a bad plan is still a valid session. The only place to stop it is before execution.

SECURITY RESEARCH BY IRONPROOF — CREDITED BYIBMGnuPGMozillaRed HatwolfSSLVideoLANDCMTK

WHAT IRONPROOF IS NOT

Not another dashboard.

  • Not monitoring

    Observability tells you what happened. Ironproof decides before it happens — a blocked action never runs.

  • Not an AI guardrail

    No language model sits in the decision path. The same request under the same policy always gets the same verdict.

  • Not a penetration test

    A test samples cases. Ironproof proves a property across every modeled sequence — or returns the one that breaks it.

  • Not a platform replacement

    Ironproof does not hold funds or custody keys. It runs in your environment, in front of the systems you already operate.

What Ironproof is: a deterministic gate before execution, a proof about the policy, and a sealed record of every decision.

WHERE IT APPLIES

Move money. Grant access.
Delete records. Ship a change.

The actions that cannot be taken back once they run. For those, authorization stops being a setting and becomes infrastructure.

  • Banking & payments

    Wires, refunds and transfers · Payee changes and daily limits · Real-time payments

    OSFI E-23 · OSFI B-13 · RPAA · AML programs

  • Mortgage & lending

    Approvals outside underwriting limits · Funding and disbursement · Changes to payout details

    OSFI B-20 · PCMLTFA (mortgage sector, since Oct 2024)

  • Insurance

    Automated claim approvals · Underwriting decisions · Payouts

    OSFI E-23 · AMF guideline on AI

  • Online gaming

    Deposit and betting limits · Payouts · Self-exclusion holds

    AGCO Registrar’s Standards (Ontario)

  • Government & defence

    Updates to official records · Approvals and spending · Access to sensitive systems

    TBS guidance on agentic AI · ITSG-33

  • Healthcare

    Access to patient records · Changes to orders and prescriptions · Data exports

    PHIPA · Law 25 · PIPEDA

  • Energy & critical infrastructure

    Setpoint and configuration changes · Remote operations on control systems · Production deployments

    IEC 62443 · NERC CIP

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.

WHY NOW

Code is starting to move money on its own.

Canadian regulators and banks have put dates on it. Each item links to its source.

  1. Sep 1, 2026

    EY: 52% of banks have piloted agentic AI, only 16% have fully deployed use cases. “A bank cannot simply say an AI system is governed. It must be able to prove it.”

    EY, How governed intelligence can scale agentic banking↗

  2. Sep 10, 2026

    OSFI states that tokenized deposits are not legally distinct from traditional deposits. The existing rules apply to them.

    OSFI, statement on tokenized deposits↗

  3. Sep 22, 2026

    Six Canadian banks announce they are exploring a CAD tokenized deposit solution, aiming for faster, more efficient and programmable payments.

    Joint release, Newswire↗

  4. May 1, 2027

    OSFI Guideline E-23 on model risk management takes effect. Its definition of a model explicitly includes AI/ML methods.

    OSFI, Guideline E-23↗

When a payment can release itself on a condition, someone has to verify the condition before it executes.

WHAT ONLY A PROOF DOES

Rules checked one by one — or the whole policy proven.

A gate that checks each rule against each request can pass every rule while a sequence of compliant actions still breaks what the policy was meant to prevent. Ironproof checks the policy as a whole: it returns the exact sequence that breaks it, or the proof that none exists.

A test tells you what it tried. A proof tells you what’s impossible.

Proven within the boundary you define. The certificate states that boundary.

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 — which is why this is not an AI problem with an AI answer.

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.

HOW IT WORKS

Prove. Enforce. Seal. Verify.

Ironproof mathematically checks that no reachable sequence of actions can cross the defined authorization boundary.

Your written policy is compiled into mathematics by a deterministic compiler — the same one the runtime uses. A differential check fails the build if the two ever diverge.

  1. 01

    Prove

    Before deployment, Ironproof establishes that the defined policy holds across the modeled action space.

  2. 02

    Enforce

    At runtime, every requested action is checked deterministically before execution.

  3. 03

    Seal

    Each decision is sealed at execution time — SHA3-512 digest, dual Ed25519 + ML-DSA-65 signature — binding the action, the policy version and the verdict into one artifact.

  4. 04

    Verify

    The certificate is re-checked against its sealed inputs: the same verdict must come back, or the seal is broken.

The theorem that ties the runtime fast path to the full formal model, and the equivalence checks behind it, are in the technical record.

VERIFY A PROOF

Check a Real Proof Yourself

Load a real sealed dossier and verify it right here — Ed25519 + ML-DSA-65 signatures, the SHA3-512 chain, and the temporal anchor that pins when, entirely in your browser. Then load a tampered one and watch it get rejected. No dashboard, no server, no trust required.

IRONPROOF · SEAL VERIFIERREADY

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 →

THE SAME ENGINE

Same proof engine. Proven on real vulnerabilities.

Findings by Dominik Blainand Cobalt, credited on the projects’ own repositories — published research, assigned CVEs and public upstream acknowledgements.

CVE-2026-41682
VIEW TECHNICAL RECORD

DESIGN PARTNER PILOT

Start with one action type.

A fixed-scope pilot on a single action your automation already performs. You keep the certificate, the gate and the sealed records.

  1. 01

    Pick the action

    One action type your agents or scripts already run — a transfer, an access grant, a deletion, a deployment — and the rules that govern it today.

  2. 02

    Prove the policy

    We encode the rules, search for sequences that pass every rule yet break the intent, and prove the corrected policy holds.

  3. 03

    Enforce and seal

    The gate runs in your environment, in front of the action. Every decision, allow or block, is sealed.

  4. 04

    Verify without us

    Your risk team or auditor re-checks the certificate and the records on their own machine.

A GOOD FIT IF

  • An agent, API or script can already execute the action without a person clicking approve
  • The rules exist on paper — limits, approvals, windows, holds
  • Someone will be asked to show that those rules actually held

Check every action. Run what’s proven. Stop the rest.

Probably safe is not
provably impossible.

Agents now move money, grant access and change production on their own. We show you exactly where your policy breaks, or prove that it can’t. Then every action is checked before it executes: what’s authorized runs, sealed; what isn’t never executes.

START A PILOT