VertRule

When AI workflows fail, can you prove why?

VertRule helps teams prove what happened across agent actions, provider behaviour, and system execution.

Provider run verified · CCS-2026-05-04
Agent actions Provider drift Evidence review

Proof has to cover the whole AI workflow.

A failed workflow can involve an agent action, a provider behaviour change, and a system-side effect. VertRule organizes those signals into evidence your team can review, explain, and defend.

Why did the agent attempt this action?

Tool calls become evidence before they become damage.

VertRule records the attempted action, policy decision, reason, and receipt so the team can explain what was stopped and why.

action execute_sql

statement DROP TABLE sessions

verdict denied

receipt verified

Verify a receipt →

A fit when agents can make production-changing moves.

The strongest first use case is an agent workflow that is already useful enough to deserve access, but risky enough that a single bad action would create real operational or compliance pain.

  • Code agents

    repos, protected branches, release automation

  • Ops agents

    databases, incident response, internal APIs

  • Platform agents

    CI/CD, deployments, privileged changes

Best first pilot

Pick one active workflow, put VertRule in front of one system boundary, and measure allowed actions, denied actions, policy reasons, and receipt verification.

Scope that pilot →
AI Agent
VertRule
Policy decision
Allow
Deny
Repo · Database
CI/CD · Internal API
Blocked
Receipt

Receipt: verifiable evidence of what was attempted, what was allowed or blocked, and why.

Intercept

Every agent action passes through VertRule before it reaches a repo, database, deployment target, or external API.

Decide

Deterministic policies evaluate the action and return allow or deny. No heuristics, no probabilistic detection. The same input always produces the same verdict.

Prove

Each decision produces a cryptographic receipt — BLAKE3 digest, JCS canonical form. Independently verifiable, permanently auditable.

Same agent. Same task. Less blast radius.

An incident-response agent with real system access reads logs, queries production, and opens a safe rollback PR. When it tries destructive SQL, a protected-branch force push, or unapproved data egress, VertRule blocks the action before execution and records the decision.

Policy

[email protected]

Determinism policy

Read operations on governed tables are permitted
No destructive SQL on production tables
All collections use ordered iteration

Runtime

vertrule-runtime

$

Every decision produces a receipt

The receipt is evidence. Each one is independently verifiable.

Receipt envelope denied

event_hash befdf1a1...680e

action execute_sql

statement DROP TABLE sessions

policy db-safety@1

reason Destructive SQL blocked by policy

This receipt is a real verifier-passing artifact. Verify it yourself.

One control point for every agent boundary

Deploy VertRule in front of the systems your agents can touch. Start with one workflow, then expand policy coverage over time.

Repos

Force pushes, direct commits to protected branches

Databases

Destructive SQL, schema mutations, unbounded queries

CI/CD

Unapproved deployments, pipeline modifications

Internal APIs

External data transfers, privilege escalation

Proof is available when you want it.

VertRule decisions are deterministic and produce receipts that can be independently verified.

BLAKE3

befdf1a174e8fd225e0b584fb68214d19f2fb832a43193708e33fb92bedc680e

New to agent governance?

Read the practical explainer — category, control point, and how a pilot starts. Agent Governance, explained →

Depend on a closed AI provider?

Provider Sentinel creates sealed behaviour baselines and reports drift under the same capture policy. Provider Sentinel →

Scope the first boundary before agents scale.

Bring one workflow where an agent can touch code, data, deployment, or an internal API. We will define the boundary, policies, receipts, and success criteria before anything expands.