AI pentesting agents exposed a two-step exploit chain in Jolt

At a glance

What this is: Veria Labs says an AI pentesting agent found a two-step exploit chain in Jolt by combining a suspected Fiat-Shamir ordering issue with a Dory polynomial commitment binding gap.

Why it matters: This matters because application security teams need to reason about how individually ambiguous findings become exploitable only when dependency behaviour removes the verification step that was supposed to stop them.

Context

A zkVM can be secure in one layer and still fail when a dependency or verifier assumption does not hold. The security gap in this article is not a single coding error in isolation, but the way proof-generation steps and downstream commitment checks have to be reasoned about together.

That is why code-review workflows that score findings one at a time miss the real risk. When a first issue is intended behaviour but a later dependency breaks the safety check, exploitability emerges only from the chain, not from either finding alone.

For security teams working on cryptography-heavy codebases, the governance problem is the same as in identity systems: trust boundaries have to be verified end to end, not assumed because each component looks acceptable on its own.

Key questions

Q: What breaks when a proof stage is intended behaviour but the downstream binding check is weak?

A: The system can still become exploitable because the earlier stage stops being the issue and the real problem becomes whether the later stage binds the verifier to the same statement. If the binding check is incomplete, an attacker can preserve internally consistent but invalid claims and make the outer verifier accept a false result.

Q: Why does chained vulnerability analysis matter more than single-finding scoring in cryptographic code?

A: Because the first issue may be harmless until another component removes the safety net that was supposed to stop it. Single-finding scoring misses exploitability that only appears when transcript logic, opening proofs, and dependency behaviour are evaluated together. Chaining analysis shows whether separate weaknesses compose into one working attack path.

Q: How can security teams tell whether an apparent proof anomaly is actually exploitable?

A: They need to test whether the final acceptance condition still enforces the exact object, point, or value the verifier believes it is checking. If the proof remains self-consistent while the verifier’s target is different, the anomaly is not just cosmetic. That is a real exploitability signal, not a false positive.

Q: Should teams trust AI pentesting agents to follow dependency chains in complex codebases?

A: Yes, but only if the workflow preserves context across dead ends and does not discard findings when the first hypothesis fails. The value is in tracing how one layer’s assumption depends on another layer’s implementation. Without that, the agent behaves like a conventional scanner and misses chained exploits.

Technical breakdown

Why chained proof failures matter in zkVM verification

Zero-knowledge virtual machines rely on multiple proof stages that each contribute a different assurance property. In a Fiat-Shamir-based sumcheck, verifier challenges are derived from the transcript, then later stages bind claims to those challenges. That means the security of the whole system depends on the final commitment or opening proof enforcing the same statement the verifier thinks it is checking. If any later stage weakens that binding, the earlier stage can become exploitable even when it was correct by design. The important technical lesson is that exploitability often appears only across stage boundaries, not within a single function or file.

Practical implication: Review proof systems as chains of dependent checks, not isolated assertions.

How a polynomial commitment binding gap creates false assurance

A polynomial commitment scheme is supposed to tie a claimed evaluation to a specific polynomial and opening point. In this article, the issue was that the ZK verifier accepted an internally consistent commitment value without fully anchoring it to the verifier-derived point. That creates a subtle but serious mismatch: the proof can look self-consistent while actually validating a different statement than the one the outer verifier expects. In practice, this is the cryptographic version of a misplaced trust boundary. The surrounding protocol may be correct, but the final acceptance condition no longer proves what the system claims to prove.

Practical implication: Audit commitment bindings against the exact statement the verifier derives.

Why AI pentesting agents can outperform single-finding scanners

Traditional scanning often treats each issue independently and stops when a lead appears non-exploitable in isolation. An AI pentesting agent that preserves context can keep following that lead into dependencies, then revisit the original suspicion once the downstream control is understood. That is the difference between finding a warning sign and proving an attack path. In cryptographic codebases, where apparently harmless ordering or transcript logic may be intentional, the value lies in correlating partial signals across layers until either the exploit is proven or the chain breaks.

Practical implication: Use context-preserving review methods for dependency-rich codebases and protocol implementations.

NHI Mgmt Group analysis

Exploit chains are now the real unit of security analysis, not isolated findings. The article shows how an intended proof-ordering property only became dangerous when a downstream dependency failed to enforce the correct binding. That is the same governance problem security teams face across cryptography, cloud, and NHI systems: a control can look valid until its surrounding assumptions are tested together. Practitioners should treat dependency-aware chaining as a first-class review discipline, not a niche pentest trick.

The named failure mode here is binding gap dependency blindness. The system did not fail because the first stage was obviously wrong. It failed because the final verifier accepted a proof that was internally coherent but not anchored to the verifier’s own opening point. That is a control-gap problem, not a code-style problem. Security programmes should map where one layer’s assurance depends on another layer’s exact interpretation of the same statement.

AI pentesting agents are useful when they preserve context across dead ends. The article’s key claim is not that automation found a single bug faster, but that it refused to discard a lead when the first hypothesis proved intended. That is a materially different operating model from single-finding scanners. For teams evaluating AI-assisted assurance, the question is whether the workflow can follow dependency boundaries deeply enough to surface chained exploitability.

Cryptographic verification needs the same lifecycle discipline that identity systems apply to trust decisions. In both cases, acceptance is only valid if every handoff is bound to the same subject, point, or authority. When a later stage checks a different object than the one the earlier stage implied, the governance model collapses. Security architects should design controls around the exact object being trusted, not the component that merely passes it along.

Application security is moving toward contextual reasoning over layered assurances. Veria Labs’ result suggests that the most valuable analysis will come from systems that can trace claims through dependencies, not just flag local anomalies. That does not make human review obsolete. It does mean practitioners should expect more value from tools that can keep the whole exploit path in view and less from tools that stop at the first plausible explanation.

From our research library:

• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Chained verification flaws are a governance problem as much as a code problem. Security teams need to stop treating protocol stages as independent assurance islands, because the exploit only exists when one layer’s assumption depends on another layer’s exact behaviour. The practical shift is to review trust boundaries across the whole proof flow, not only where a local bug first appears.

AI-assisted review becomes more valuable when it can retain context across dependencies. Veria Labs’ example suggests the differentiator is not raw bug detection, but whether an agent can hold an apparent false positive long enough to test whether another layer makes it real. That is the operational standard practitioners should use when assessing AI pentesting output.

43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec. In code-heavy assurance work, the concern is broader than leakage alone: models must also preserve enough context to distinguish intended behaviour from a genuine exploit path.

For practitioners

• Map verification dependencies end to end Trace every proof stage, transcript input, and opening check so you can see which later component is responsible for rejecting a malformed claim.
• Review ambiguous findings as potential chain links Do not close a finding just because the first hypothesis looks intended or non-exploitable. Re-test it in the presence of downstream checks and dependency behaviour.
• Validate the exact binding target Confirm that the object accepted by the final verifier is the same object the protocol claims to open, especially when commitments hide values in ZK mode.
• Prioritise context-preserving security review Use workflows that keep intermediate hypotheses, code paths, and dependency relationships alive long enough to test whether a multi-step exploit exists.

Key takeaways

• The article shows that a proof can appear valid at one layer and still be exploitable once a later dependency weakens the binding guarantee.
• The demonstration matters because it turned a false computation result into an accepted proof, which is exactly the kind of chained failure single-finding tools miss.
• Security teams should review verification chains, not just isolated findings, because exploitability often emerges only when multiple small weaknesses compose.

Key terms

• Fiat-Shamir Transform: A method that replaces interactive verifier challenges with challenge values derived from a transcript sponge or hash. Its soundness depends on every message that should influence the challenge being absorbed first, otherwise the prover can manipulate later steps after seeing the challenge.
• Polynomial Commitment: A polynomial commitment is a cryptographic scheme that lets a prover commit to a polynomial and later prove evaluations at selected points without revealing the whole polynomial. The verifier checks that the committed polynomial and the claimed value are consistent at the stated point, which is essential for soundness.
• Zero-Knowledge Virtual Machine: A virtual machine that proves a computation was executed correctly without revealing the underlying data. The proof system typically combines transcript generation, commitment schemes, and opening proofs, so assurance depends on every stage agreeing on the same computation and the same verification target.
• Dependency Chain: A dependency chain is the set of direct and indirect libraries, runtimes, and services that an application relies on to operate. In practice, it determines whether an upgrade can happen cleanly or whether multiple coordinated changes are needed before the target version can be adopted safely.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps security practitioners connect identity controls to wider assurance and governance decisions.