Runtime assurance for agent-written code

Your agent writes the PR. We try to break it before you merge.

Vesperia turns critical business invariants into executable adversarial tests against risky code changes — then lets your application's real runtime decide the result.

Become a design partner See how it works

Early prototype. Currently working with design partners.

The difference

Not another AI code reviewer.

Review models can identify suspicion. Vesperia turns that suspicion into something your application can prove or disprove.

AI code review

Analysis layer

“This authorization change looks risky.”

Model opinion
Static context
Another comment in the PR

Vesperia

Assurance layer

“Tenant A accessed Tenant B's resource.”

Generated counterexample
Executed against the application
Reproducible evidence

The model decides what to challenge.

Your application's runtime decides whether the challenge succeeds.

A concrete assurance run

From invariant to evidence.

One risky line. One generated challenge. A verdict grounded in the behavior of the test runtime—not a confidence score.

Example · tenant boundary

01 / 02

Invariant + risky PR

tenant-isolation

A user belonging to Tenant A must never access resources belonging to Tenant B.

async function getResource(id, user) {
- return Resource.findOne({ id, tenantId: user.tenantId })
+ return Resource.findOne({ id })
}

03 / 04

Generated counterexample

ACTOR Tenant A user

REQUEST GET /api/resources/tenant-b-resource

Expected response 403 assert(response.status === 403)

05 / 06 / 07

Runtime evidence

Observed response 200

Invariant violated: tenant-isolation

DETERMINISTIC VERDICT BLOCK Reproducible in the existing test environment

High-consequence logic

The rules your business cannot afford to break.

Generic best practices are not enough. The useful rules are specific to how your product is allowed to behave.

AUTHZ_01

Authorization

Non-admin users must never perform admin actions.

TENANT_02

Tenant isolation

Tenant A must never read or mutate Tenant B data.

PAYMENT_03

Payments

A payment or refund must never exceed its permitted state.

STATE_04

Stateful workflows

Retries and replays must never cause duplicate side effects.

How it works

A short path from intent to proof.

Vesperia operates at the boundary between a risky change and your existing test environment. Production traffic is not the test bed.

Define

Define invariants

invariants:
  - id: tenant-isolation
    severity: critical

    description: >
      A user from one tenant must never access
      resources belonging to another tenant.

Challenge

Vesperia tries to falsify them

It reads the risky change and relevant application context, then proposes executable counterexamples.

01: Changed diff
02: Relevant application paths
03: Explicit invariant

Execute

Your runtime produces the evidence

The generated test executes in your existing test environment.

PASSChallenge did not reproduce a violation

REVIEWTest needs human attention

BLOCKInvariant violation reproduced

A broken generated test is REVIEW, never BLOCK.

Operating principles

Evidence over AI confidence.

Models are useful for generating the right challenge. They are not the authority on whether your system behaved correctly.

Executable evidence model opinions

Deterministic verdicts confidence scores

Explicit invariants generic best practices

Your runtime another model judging another model

Status / prototype

We're early.

Vesperia is currently a focused prototype for teams experimenting with coding agents in production.

The first version is GitHub-first and focuses on high-consequence business logic such as authorization, tenant boundaries, payments and stateful workflows.

We're looking for a small number of engineering teams willing to run it in shadow mode and tell us where it fails.

Become a design partner