Runtime Assurance Stack · AI Security · Advisory default

AI security doesn't end at the decision.
It must be verified at execution.

The Runtime Assurance Stack connects AI-related risk discovery, adversarial testing, authorization decisions, execution-boundary controls, and independently verifiable evidence. For a defined security guarantee and tested scenario, it evaluates the evidence and returns PROVEN, DISPROVEN, or UNKNOWN.

Book a supervised design-partner POC See the stack

Two weeks. One workflow. INV-PIN-001. Advisory by default. One tenant, one host. Independent third-party audit required before any production or GA claim.

10/10
Replay resistance
G7 harness · two live processes
10/10
Redis fail-closed
G7 harness · Redis stopped
3/3
Key rotation
G7 rotation reps · real containers
66/66
Tamper mutations rejected
G3 tamper corpus · unmodified baseline accepted

Results reported by the specified test harness against evidence/2026-10-29-bound (revision c628419), G0→G10 WITNESSED. These are harness-scoped results, not production-wide guarantees. The live INV-PIN-001 demo separately rejected 109 tamper mutations; that is a different run and is not summed with the G3 corpus above.

The workflow

Six stages. One workflow.

The architecture connects controls with testable guarantees and verifiable evidence. Each stage has an output the next stage consumes. Nothing manufactures a successful result when a prerequisite is missing. The Assurance Compiler appears at stage six because that is where its verdict lands, but it also states the guarantee as a testable mission before stage two; one workflow, with the compiler at both ends of it.

01
LEARN
Phantom
Finds a relevant supply-chain risk. Output: a reviewed finding.
02
ATTACK
Crucible
Runs the defined CI/CD attack scenario. Output: attack trace.
03
DECIDE
VyriAI
Policy decides; on allow, issues a narrow signed token. Output: decision.
04
ENFORCE
VetoKernel
Applies the authorization at the boundary. Output: signed receipt.
05
RECORD
Receipts + audit
Signed receipt + consumption record for later re-verification.
06
VERIFY
Assurance Compiler
Deterministic verifier. Returns PROVEN · DISPROVEN · UNKNOWN.
The portfolio

Six products. One question each.

Complementary roles, not interchangeable products. Detecting a risk is not the same as blocking an attack, and an authorization decision is not the same as proof that a forbidden side-effect was prevented.

01 · LEARN

Phantom

Supply-chain intelligence. Scans packages and workflow files; emits reviewed findings a person approves before anything else happens.

  • Static analysis of npm and PyPI packages with evidence per finding.
  • Install-time critical-combo risk floors (POSTINSTALL + CREDENTIAL / PERSISTENCE).
  • Destination-reputation enhancer — discord/slack/teams/telegram webhooks, pastebin, ephemeral tunnels, raw-IP:port tuples.
  • Loadable PopularityOracle (JSON overrides + optional live backend) replaces the previous hardcoded whitelist.
  • Detection quality is formally excluded from POC claims until it meets protocol targets on an independent corpus.
02 · ATTACK

Crucible / Crucible Cloud

Defined attack-scenario testing. Local engine checks CI/CD workflow pinning; the cloud ingests results and detects regressions.

  • Local crucible attack on a workflow — unpinned Action is scored 85/100, SHA-pinned 100/100.
  • Crucible Cloud: FastAPI service for result ingest, dashboard and regression gates with tenant isolation.
  • Explicit scope — local mode covers one static check (GitHub Actions pinning); does not cover pull_request_target abuse, script injection or secret exposure.
03 · DECIDE

VyriAI

Policy gateway. Evaluates an agent's action against policy and issues a short-lived signed authorization token (SAT) bound to tenant, agent, tool and parameters.

  • Allow / deny per request, with a scoped SAT only on allow.
  • Tamper-evident audit log; a denied action produces no token.
  • Production-mode guardrails: HTTPS-only, startup refusals, Redis/Postgres outages fail closed.
  • HA / TLS termination checks pass on a single-host two-gateway topology.
04 · ENFORCE

VetoKernel

Enforcement and signed receipts at the execution boundary. Replays, expired or mismatched authorizations are refused; concurrent attempts across processes converge to a single use.

  • Single-use authorization bound to the exact action, target and parameters.
  • Signed receipt + signed consumption record of when the authorization was used.
  • Default advisory mode; strict mode under a specific guarantee profile.
  • Two-process shared-Redis replay: 10/10. Redis-outage fail-closed: 10/10. Key-rotation: 3/3.
05 + 06 · RECORD / VERIFY

Assurance Compiler

Compiles a security guarantee into a testable mission, and provides the deterministic verifier that rechecks saved evidence in a fresh process with keys the auditor supplies.

  • Three verdicts, no shortcuts — PROVEN, DISPROVEN, UNKNOWN.
  • Offline, deterministic verifier — not an ML model; not a language model.
  • Two signatures per artifact — enforcer receipt and compiler verdict; tamper corpus 66/66 rejected.
COMPLEMENTARY

MCP-Proof

Dependency-free command-line scanner for MCP tool definitions. Flags hidden instructions, typosquats and other tool-surface poisoning before a tool is trusted.

  • npx mcp-proof ./tools.json — tool-surface scanner, Node 18+.
  • Covers tool poisoning, typosquats, hidden unicode / base64, exposed transports.
  • Published to npm (0.3.21). Explicit scope: pattern-based detection on supplied metadata, not runtime behavior.
The verdicts

Three verdicts. No shortcuts.

Verdicts come from a deterministic verifier, not from a language model. Missing or unverifiable evidence is never silently treated as success.

PROVEN

The required evidence satisfies the guarantee. The forbidden action was attempted, denied at the boundary, and the signed evidence verified end to end.

DISPROVEN

An executed counterexample demonstrates that the guarantee failed. A concrete violation was observed and recorded; the verifier reports it.

UNKNOWN

The evidence is insufficient to decide. The system does not guess; it says so. Missing evidence is never silently promoted to a success.

Verification

Verify the evidence yourself.

The current binding is evidence/2026-10-29-bound at commit c628419. There are two different procedures, and they prove different things. Read them separately.

1 · Reproduce the package checks

From a checkout of this repository, with a Python environment at assurance-compiler/.venv, run the packaged script:

bash evidence/2026-10-29-bound/verify.sh

Repository-dependent. verify.sh resolves the verifier and its Python interpreter at fixed paths inside the repository, so it exits non-zero from a bare checkout with no .venv. It also reads the public keys bundled at g3/public_keys.json. It confirms package consistency and reproduces the tamper, replay and G10 figures. It does not establish verification against keys you obtained yourself.

2 · Verify with keys you supply

Obtain the public keys through a channel separate from this package, keep your own copy, and run the standalone verifier with your copies:

python scripts/independent_verifier.py \
  evidence/2026-10-29-bound/g4/proven_artifact.json \
  --public-keys /path/to/your-copy-of-public-keys.json \
  --compiler-keys /path/to/your-copy-of-compiler-key.json \
  --require-compiler-signature \
  --test-tamper

Expected: Verdict: PROVEN | Checks: 8 passed and Tamper resistance: 66/66 (100%) rejected; with --json the report also shows compiler_signature_verified: true. This is the check that does not take our word for the key material. It still requires this repository and its Python environment.

What the tamper corpus covers. Two independent signatures are checked. The enforcer signs the receipt — what happened at the boundary. The compiler signs the evaluation body, including the receipt ID — which guarantee judged it. The 66 mutations cover the signed receipt, binding and consumption material plus the guarantee identity, and every one is rejected. Changing enforcement.receipt_id returns REJECTED: Receipt ID does not match signed receipt hash; relabelling the guarantee returns REJECTED: compiler artifact signature failed. What no signature covers is the compiler's own execution: an auditor must still trust that it ran the invariant it says it ran.

expected output · standalone verifier 
== fresh-process verifier (G4 PROVEN artifact) ==
verdict:           PROVEN
verifier_version:  1.1.0-independent
checks_passed:     8
verifying_key_id:  dd08cc4b

== tamper corpus ==
rejected:          66 / 66
baseline_verified: True

== G10 candidate status (evidence/2026-10-29-bound) ==
status:            READY_FOR_INDEPENDENT_AUDIT
release_decision:  NOT_ISSUED
replay:            10/10  fail_closed: 10/10  key_rotation: 3/3

PASS: Artifact independently verified

What this is not. Re-running a deterministic verifier is not a third-party security audit, certification, or proof of universal non-bypassability. No external party has audited this stack. READY_FOR_INDEPENDENT_AUDIT means the package is complete enough to hand to an auditor; it does not mean an audit happened. release_decision: NOT_ISSUED is the harness default, and the launch GO is a separate human decision, not a production or GA approval.

Scope boundaries

What the fixture run shows — and what it does not.

Credibility is an asset. We state the limits in the same breath as the capability.

What the recorded fixture run shows

  • On the recorded fixture scenario, the defined unauthorized-release test produced the documented result against a registry we control — not your registry.
  • In the twelve-case INV-PIN-001 demo, all 4 unmodified controls were accepted, and the live demo rejected 109 tamper mutations.
  • Signed receipts are single-use, action-bound and refuse replays, expired tokens and wrong agents.
  • The saved evidence re-verifies in a fresh process, and passes again against key copies supplied from outside the package.
  • G3 tamper corpus 66/66 rejected; G7 replay 10/10, Redis fail-closed 10/10, key rotation 3/3.

What we do not claim

  • We do not claim non-bypassability or universal coverage of every executor.
  • During your POC the workflow is advisory. We do not claim that this mode blocks actions in your environment, and we do not merge your engagement result with the fixture result.
  • No independent third-party audit yet; required before any production or GA claim. Re-running our verifier is not an audit.
  • Phantom detection rate — not quoted; detection quality is excluded from POC claims.
  • We do not hold SOC 2; compliance endpoints return catalogs, not attestations.
The engagement

The supervised design-partner POC.

Two weeks. One guarantee: GitHub Actions pinned to immutable references (INV-PIN-001). One workflow, one tenant, one node. Advisory mode: nothing is executed or blocked in your environment.

You provide

  • Workflow files or dependency manifest and permission to scan them in our environment.
  • One named witness on your side.
  • The workflow you want to test and the finding you approve for review.
  • Explicit approval to issue one authorization for one test call.

You receive

  • A witnessed session on your own inputs — not our fixtures.
  • An evidence package you verify yourself with keys you supply.
  • A written summary of what worked, what did not, and what you would need next.
  • A debrief: would you use this evidence in a security review, which guarantee would you test next, and what stopped you from trusting it.
Book a supervised design-partner POC Request a technical deep-dive

Two weeks. One workflow. INV-PIN-001. Advisory by default.

Common questions

FAQ.

What is the Runtime Assurance Stack, in one sentence?
A connected workflow — Learn, Attack, Decide, Enforce, Record, Verify — that returns PROVEN, DISPROVEN or UNKNOWN against a defined security guarantee, from saved evidence that an outside auditor can recheck with keys they supply.
What does the POC actually prove?
On one host, one fixture registry and advisory mode: unauthorized releases did not happen, and the saved files verify in a fresh process. It does not prove non-bypassability, universal coverage, production readiness or GA. An independent third-party audit is required before any production or GA claim.
How do I verify the evidence package myself?

There are two procedures, and they prove different things:

Reproduce the package checks: from a checkout of this repository, run bash evidence/2026-10-29-bound/verify.sh. It is repository-dependent and reads the two public keys bundled at g3/public_keys.json and g3/compiler_public_key.json.

Verify against your own key copies: obtain both public keys through a channel separate from the package, then run python scripts/independent_verifier.py evidence/2026-10-29-bound/g4/proven_artifact.json --public-keys <your copy> --compiler-keys <your compiler key copy> --require-compiler-signature --test-tamper. Expected: Verdict: PROVEN | Checks: 8 passed and Tamper resistance: 66/66 (100%) rejected.

The 66 tamper mutations cover the signed receipt, binding and consumption material, and the compiler-signed guarantee identity; all are rejected. Relabelling the guarantee breaks the compiler signature. What no signature covers is the compiler's own execution, so an auditor must still trust that it ran the invariant it claims to have run.

Neither procedure is a third-party audit or certification, and neither proves universal non-bypassability.

Is enforcement always advisory?
Advisory by default for the POC. Strict mode exists under a specific guarantee profile and refuses on a failed check. The product does not claim non-bypassability.
Do you hold SOC 2 or similar attestations?
No. Compliance endpoints return structural control catalogs, not audit attestations. We do not hold a SOC 2 report. An independent third-party audit remains the gate before any production or GA claim.
Why not quote a Phantom detection rate?
The current held-out detection rate on a synthetic corpus is 75% against an 80% target, and the benign false-positive rate is 8.9% against a 2% target. Both targets are unmet. Phantom detection quality is formally excluded from the POC claims until it is validated on an independent real-malware corpus.
What data do you keep from a scan?
By default we keep only each file's name and SHA-256 unless you approve more. No credentials and no full manifests are stored in the evidence package. Secrets live only in a mode-600 environment file.
Supervised design-partner POC

Book a two-week POC.

One workflow file or dependency manifest that you supply, run in our environment with one of your people watching. Advisory by default; no production or GA commitment.

or email vyriaipro@gmail.com