IronVise

Stop the risky tool call. Keep the proof.

Pre-execution firewall and tamper-evident flight recorder for AI agents. IronVise blocks risky tool calls, such as reading SSH keys outside the workspace or rm -rf /, before they run, and exports offline-verifiable audit certificates for EU AI Act Article 12 record-keeping (applies to Annex III high-risk systems from 2 December 2027) and ISO 42001 evidence. Article 12 requires high-risk AI systems to keep automatic logs over their lifetime. It does not require those logs to be hard to edit afterwards. IronVise runs agent actions through policy checks and OS sandboxes and records every one in a hash-chained, Ed25519-signed ledger that a third party can verify offline - without your database, your keys, or your cooperation. Prototype; not independently audited.

It complements your sandbox rather than replacing it. Docker Sandboxes (sbx), Perplexity SPACE or E2B limit what an agent can reach once a command runs; IronVise decides whether the command runs at all and keeps a signed record a third party can check. Use both.

Built for teams running AI in high-risk workflows: security, compliance, platform engineering, and enterprise operations.

Get Started Watch Demo

Use Cases

What teams can use IronVise for

Security Operations

Block unsafe agent commands before they hit infrastructure, APIs, or sensitive files.

Compliance Reviews

Produce tamper-evident evidence trails for internal and external audit requirements.

Enterprise Procurement

Show customers exactly what the agent attempted, what was blocked, and what actually executed.

Incident Forensics

Replay AI-assisted workflows with signed, hash-chained records for post-incident analysis.

Article 12 mapping Tamper-evident audit trail 4-layer AI guardrails Signed audit certificates Source available · BUSL-1.1 Article 12 mapping Tamper-evident audit trail 4-layer AI guardrails Signed audit certificates Source available · BUSL-1.1

Clarity first

What IronVise is, and what it is not

IronVise is not a crypto trading product. Here, "ledger" means a tamper-evident audit log for AI agent behavior.

What it does

Records each AI action in an append-only, hash-chained audit trail.
Prevents damage by blocking denied actions before execution (policy + guard + strict schema + Tripwire).
Detects prompt-injection and goal-hijack patterns in model output before commit/execution.
Exports verifiable evidence (.elc certificates) for customers, auditors, and regulators.
Adds optional sandbox isolation tiers for execution paths, including Firecracker on Linux and Apple Hypervisor guard isolation on supported Apple Silicon builds.

When to use it

Your AI agents run commands, call APIs, or touch sensitive files/infrastructure.
You need a hard-stop control plane, not just post-incident logs.
You must prove what happened during an AI run to security, compliance, or customers.
You are preparing for enterprise procurement, compliance reviews, or third-party due diligence.
You want replayable, cryptographically verifiable evidence instead of screenshot-based reporting.

What it does not do

It does not trade, hold, or manage cryptocurrencies.
It is not a replacement for your SIEM or ticketing platform.
It is not a universal host EDR outside IronVise-managed agent actions.
It does not guarantee legal outcomes by itself.

Flowchart

How IronVise controls AI actions

Every proposed action is checked before execution. Denied actions are blocked and recorded. Allowed actions execute and are sealed into cryptographic evidence.

See it in action

Explore an audit trail in IronVise

Explore recorded actions, policy decisions, data receipts, and verification in the current interface. This walkthrough uses demonstration data.

Who is this for?

Teams that need proof, not guesswork

Compliance Teams

EU AI Act timelines are approaching. IronVise gives you auditable evidence for high-risk AI workflows now.

Engineering Teams

If your agents run commands and APIs, you need a provable trail showing every decision and action.

Security Teams

Every action passes four validation layers before execution. Rejections are logged and reviewable.

Auditors and Regulators

Export .elc certificates and verify them offline with a standalone binary. No vendor trust required.

The Solution

Everything you need to make AI agents accountable

Core Ledger

Tamper-evident activity log

Capture every model decision, tool action, and operator approval in a timeline you can replay and verify.

4-layer semantic guard

4 layers of protection before any action executes

Policy engine, strict schema validation and Tripwire check every proposed action; the dual-LLM semantic guard adds a fourth layer when it is turned on. An action that fails a layer is blocked before it runs.

.elc audit certificates

Audit certificates you can verify offline

Export a self-contained certificate with cryptographic proofs and verify it offline using the standalone verify-cert binary.

Legal admissibility depends on jurisdiction and process; IronVise provides cryptographic evidence to support review and testimony.

Policy Studio

Define what your AI is allowed to do

Metrics

Live reliability telemetry

Active Audit

Real-time workflow traceability

Philosophy

The agent is the database

State lives in the ledger

The Rust process is a transient worker. All durable state - event log and snapshots - lives in the configured backend (PostgreSQL or SQLite). The binary has no long-term memory; it restores state from the ledger on each run.

Perceive → Propose → Verify → Commit → Execute

Proposed actions from the LLM are never trusted directly. Policy engine, guard process, then Tripwire validate every intent before commit. Intents that pass are appended to the hash-chained ledger and executed; nothing is ever updated or deleted.

Industry policy packs

SOC 2, PCI DSS v4.0.1 and OWASP Top 10 rule packs: load one with --policy crates/host/policies/soc2-audit.toml, or choose it for runs in the desktop app. ISO 42001:2023 ships as a controls mapping.

How It Works

From setup to audit proof in 3 steps

The workflow follows a deterministic progression designed for high-assurance environments.

Step 1

Create a scoped session with explicit mission and policy boundary.

Step 2

Append model and tool events while guardrails validate each operation.

Step 3

Seal the session and export verifiable certificate artifacts.

Execution health

Operational overview

Flow engine 84% in progress

Action queue 120 items remaining

System health No issues detected

How-To

Start with the right setup for your goal

Run a full audit with a verifiable export

Use SQLite for zero-config single-machine audits, or PostgreSQL for multi-agent orchestration.
Set guard configuration and keep GUARD_REQUIRED=true.
Run audit \"<goal>\", then export and verify .elc.

Choose demo vs SQLite vs PostgreSQL

Demo: fast product tour with isolated data.
SQLite: zero-config audits, certificates, anchoring, and local SIEM webhooks.
PostgreSQL: production scale plus multi-agent orchestrate / diff-audit / red-team.

Prepare evidence for auditors

Run with policy packs (SOC 2, PCI-DSS, OWASP).
Export report + .elc certificate.
Verify evidence offline with verify-cert.

Need help with setup or verification errors? See the Troubleshooting guide.

v0.8.0 · Release notes

Changelog and updates

New in v0.8: security hardening, an honest desktop first-run path, and a shorter GUI. Full README and CLI reference live on GitHub.

Fail-closed sandboxing - A sandbox that cannot be applied now aborts the action instead of silently degrading it; ECTO_SANDBOX_PERMISSIVE opts back out.

Symlink TOCTOU defence - read_file refuses to follow a leaf swapped for a symlink between validation and open, with regression tests for the race window.

Canonical v2 hashing - All write paths share one byte layout; pre-v0.8 ledgers still verify through the v1 fallback.

Demo mode labelled insecure - The demo stack names every weakening it applies and logs a startup warning; running securely covers the hardened path.

Safer embedded PostgreSQL - Startup no longer SIGKILLs whatever holds port 5432; only instances it owns are reclaimed.

Working fresh clone - make start, make demo, and the Docker demo all verified from a clean checkout.

Earlier: v0.6

Pluggable ledger backends - PostgreSQL or SQLite via DATABASE_URL; LedgerBackend trait for custom stores.

Tauri 2 management GUI - Glassmorphic desktop app: dashboard, metrics, sessions, policy editor, Tripwire, certificate export.

Python & TypeScript SDKs - Typed REST clients; LangChain LedgerCallbackHandler and AutoGen LedgerHook.

Extended webhooks - HMAC-signed SIEM egress (JSON, CEF, LEEF) for GuardDenial and TripwireRejection.

W3C Verifiable Credentials - VC-JWT on session completion; Ed25519-signed, did:key: anchored.

ISO 42001:2023 - Machine-readable control mapping (14 controls) from clauses to ledger evidence.

4-layer pre-execution checks - Policy, strict schema and Tripwire on every action; the dual-LLM guard when turned on.

Firecracker microVM sandbox - Hardware execution isolation for run_command (Linux, guest image you supply).

Offline audit certificates - Inspect signed provenance without a database or model.

.elc certificates - Five-pillar verification; standalone verify-cert binary.

Key rotation & config - Automatic session-key rotation, orchestrator policy injection, configurable bind port, DB pool scaling.

Developers

Quick start, SDKs, and CLI

Zero-friction setup: make targets on macOS/Linux, a PowerShell launcher on Windows, a Docker demo, or SQLite for local dev. Full docs on GitHub.

Quick start

Clone, then make start for the desktop GUI - it runs its own backend in-process. Or make demo for a zero-config SQLite dashboard with no Docker or PostgreSQL.

Desktop GUI: make start
Dashboard only: make demo
Windows: .\ironvise-win.ps1
Docker: docker compose -f docker-compose.demo.yml up

Quick Start on GitHub →

CLI at a glance

Serve dashboard, run audits, export reports and certificates.

serve - Observer dashboard (default http://localhost:3000)
audit "<goal>" - Run cognitive loop with policy/guard
report <session_id> --format certificate --output audit.elc
verify-certificate audit.elc - Offline .elc verification
orchestrate "<goal>" - Recon → Analysis → Verify
anchor-session <id> - OpenTimestamps timestamp
red-team --target-session <id> - Adversarial testing
prove-audit <id> - unavailable in 0.8; use certificate export

CLI reference →

Python SDK

pip install ironvise installs the Python SDK. Optional extras: [langchain] or [autogen]. sdk/python

quickstart.py

import asyncio
from ironvise_sdk import LedgerClient

async def main():
    async with LedgerClient("http://localhost:3000", bearer_token="<token>") as client:
        session = await client.create_session(goal="Audit Cargo dependencies", record=True)
        await client.append_event(session.session_id, {"step": "read", "file": "Cargo.toml"})
        await client.seal_session(session.session_id)

asyncio.run(main())

TypeScript SDK

npm install ironvise installs the TypeScript SDK. Zero runtime deps, native fetch. sdk/typescript

import { IronViseClient } from "ironvise";
const client = new IronViseClient({ baseUrl: "http://localhost:3000", bearerToken: "<token>" });
const session = await client.createSession({ goal: "Summarise quarterly report", record: true });
await client.appendEvent(session.id, { step: "retrieved_docs", count: 42 });
await client.sealSession(session.id);
const cert = await client.exportCertificate(session.id);

Audit certificates (.elc)

Five verification pillars

Every completed session can be exported as a self-contained .elc verifiable offline. SP1 proof generation is unavailable in 0.8. Auditors can run verify-cert offline without a database, model, or Rust toolchain.

Ed25519 signature

Tamper evidence; payload signed with the session keypair; no trusted third party.

SHA-256 hash chain

Gap and mutation detection; any insertion or change is detectable offline.

Merkle inclusion proofs

Efficient finding spot-checks; O(log n) verification per finding.

OpenTimestamps anchor

Timestamping; once the OpenTimestamps stamp is upgraded, proves the session existed before block N.

Goal hash integrity

Session integrity; goal cannot be redirected mid-session.