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

At a glance

What this is: Veria Labs describes how an AI pentesting agent chained a suspected Jolt proof-ordering issue with a Dory dependency flaw to forge a false zkVM proof.

Why it matters: For IAM, NHI, and application security teams, the lesson is that security review must account for chained weaknesses across code, dependencies, and verification logic, not just isolated findings.

👉 Read VERIA LABS's analysis of the Jolt exploit chain and Dory binding gap

Context

A zkVM security failure is often not a single bug, but a sequence of weaknesses that only becomes exploitable when they are combined. In application security, that means scanners and review workflows that score findings one at a time can miss the real attack path, especially when the vulnerable behaviour sits in a dependency rather than the primary codebase.

This matters to identity and access programmes because modern application trust increasingly depends on machine-to-machine verification, proof systems, and delegated components that behave like non-human identities in the control plane. When those components are chained, the governance problem is less about one defect and more about whether teams can reason across boundaries, dependencies, and runtime trust assumptions.

The article’s starting position is not unusual for mature cryptographic codebases: complex systems often look safe at the surface until a later-stage dependency check determines whether a suspected flaw is actually exploitable.

Key questions

Q: What fails when security tools evaluate findings one at a time?

A: They miss exploit chains where each issue is only dangerous in combination with the next one. A defect that looks non-exploitable in isolation can become a real break once a later dependency, control decision, or runtime state change is taken into account. That is why path reasoning matters more than severity sorting alone.

Q: Why do dependencies create hidden security risk in application security?

A: Because the dependency may implement the actual trust decision, not just support the application. If the library’s binding or verification logic is incomplete, the application can appear correct while accepting invalid state. Teams should test the security property they rely on, not simply whether the library is up to date.

Q: How can security teams know if a proof or verification flow is actually safe?

A: By checking that the same statement is bound through every stage of the flow, from transcript generation to final verification. If a component can alter the point of verification, the claimed value, or the object being checked without failing closed, the assurance model is broken.

Q: What should teams do when an exploit seems to require multiple small weaknesses?

A: Treat the combination as the risk, not the individual findings. Validate whether the weaknesses can be chained by an attacker, prioritise the dependency or control that closes the last verification gap, and keep a human review path for high-value codebases where automated scoring is too coarse.

Technical breakdown

Why chained vulnerabilities evade single-finding review

Chained exploits emerge when two or more individually incomplete weaknesses become dangerous only in combination. In this case, the first observation looked like a Fiat-Shamir ordering problem, but that alone was not enough to break the system. Security tools that judge findings in isolation often stop at that point, because they cannot model whether an earlier state change creates the precondition for a later abuse path. The real technical challenge is path reasoning across stages of a protocol, dependency, or business logic flow, where the exploit only exists after several correct-looking decisions line up.

Practical implication: reviewers need dependency-aware attack-path analysis, not per-finding triage alone.

How dependency trust can hide the actual break point

Modern applications frequently treat libraries as black boxes, but the security boundary does not stop at the import statement. If a dependency implements the final cryptographic or access-control check, then a flaw inside that dependency can invalidate the upstream assurance model even when the calling code is correct. In cryptographic workflows, that usually shows up as incomplete binding between a claim, a point of verification, and the value being proven. Once that binding fails, the surrounding application can appear to verify something it never actually checked.

Practical implication: audit the security properties of the dependency, not just its version and CVE status.

Why proof systems need end-to-end consistency checks

Zero-knowledge proof systems depend on consistency between transcript ordering, commitment objects, and final verification. A verifier may appear to reject invalid claims, but if the commitment layer does not tie the proof to the exact statement being checked, an attacker can shift the proof context while preserving local consistency. That is the architectural lesson here: cryptographic assurance is only as strong as the weakest binding step in the chain. The system can be mathematically sophisticated and still fail if the verification boundary is incomplete.

Practical implication: validate cryptographic bindings end to end, especially where hidden commitments meet public verification.

Threat narrative

Attacker objective: The attacker’s objective is to obtain acceptance of a false computation result as if it were a valid cryptographic proof.

1. Entry occurred through a suspected verifier inconsistency in the Jolt sumcheck stage, where the transcript ordering looked exploitable before later checks were considered.
2. Credential-like trust was then abused through a Dory ZK binding gap that let the proof remain self-consistent while being detached from the verifier’s intended opening point.
3. Impact followed when the agent forged an accepted proof for a program whose real output should have been false, showing a full proof-integrity compromise.

NHI Mgmt Group analysis

Chained assurance failure is the real security problem here. The exploit did not depend on one dramatic break. It depended on two smaller weaknesses becoming exploitable only when the agent reasoned across stages and across a dependency boundary. That is a useful warning for any programme evaluating cryptographic systems, NHI workflows, or delegated machine trust: local correctness does not equal system safety. Practitioners should treat multi-stage reasoning as a first-class governance requirement.

Dependency blindness is a governance gap, not just a tooling gap. The article shows why scoring findings one at a time underestimates exploitability. If a dependency performs the final trust decision, then the application inherits that dependency’s assurance model whether the team knows it or not. Dependency-bound proof drift: a failure mode where the application believes it is verifying one statement while the dependency verifies another. Teams should use that framing when reviewing cryptographic libraries, agent toolchains, and identity-bound verification flows.

AI pentesting is now competing with manual depth, not replacing it. The most important part of the narrative is not that an agent found a bug, but that it preserved context long enough to decide a dead end was worth following. That mirrors the direction of modern application security: deeper code understanding, more dependency traversal, and less reliance on single-signal automation. Security leaders should expect agentic review to matter most where exploitability depends on stitching findings together.

This pattern reinforces why identity governance must extend into software trust chains. When proofs, tokens, or machine-authenticated assertions depend on hidden runtime components, those components function like non-human identities with delegated authority. The governance question becomes who or what is allowed to assert validity, under which binding, and with what verification scope. Practitioners should align trust-chain review with identity and privilege review, not treat it as a separate cryptography-only concern.

What this signals

Dependency-bound proof drift: application teams should expect more failures where the application’s intended trust statement diverges from what a dependency actually verifies. That means code review, library review, and cryptographic assurance have to be assessed as one control plane, not three separate tasks.

For programmes running machine-authenticated workflows, the practical signal is whether review tooling can follow a finding across layers without dropping context. If it cannot, the team needs stronger dependency provenance checks, more explicit verification boundaries, and tighter ownership of libraries that make final trust decisions.

For practitioners

• Map multi-stage exploit paths across dependencies Review security findings as potential chains, not isolated issues. Force analysts to trace whether an apparently harmless defect becomes exploitable only after a later-stage check, especially when the check lives in a third-party library or proof component.
• Audit verification boundaries, not just application code Identify where the real trust decision occurs in cryptographic and delegated systems. Confirm that the verifier, the commitment, and the claimed value are bound to the same statement and that a dependency cannot silently shift that boundary.
• Require dependency-level exploitability testing Test whether an imported library is merely vulnerable in theory or actually reachable from your code path. Prioritise packages that sit on the final validation path, because those are the ones that can convert a local flaw into a system-wide failure.
• Extend identity governance to machine trust components Treat proof services, signing components, and delegated validators as governed machine identities. Assign ownership, review their authority boundaries, and document which assertions they are permitted to make on behalf of the system.

Key takeaways

• The article shows that exploitability often emerges from a chain of small weaknesses rather than a single obvious flaw.
• The most important control gap is incomplete binding at the dependency layer, where the real verification decision can drift from the application’s intent.
• Security teams should prioritise dependency-aware path analysis and end-to-end verification checks for cryptographic and machine-trust workflows.

Key terms

• Exploit Chain: A sequence of vulnerabilities or malicious steps that work together to move from initial exposure to full compromise. In practice, one weakness may not be enough on its own, but chained weaknesses let attackers bypass normal protections and reach code execution, data theft, or device control.
• Disclosure Boundary: A disclosure boundary is the point where permitted internal access becomes an external share, export, or secondary use of data. In healthcare, these boundaries matter because privacy failures often happen when identity controls allow copying or forwarding PHI beyond the original approved purpose.
• Dependency-Layer Trust: Dependency-layer trust is the assumption that imported code will preserve the security property the application relies on. That assumption is often invisible until a library handles the final check, making dependency review a control issue as well as a software maintenance issue.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full article

VERIA LABS's full analysis covers the technical detail this post intentionally leaves at the governance and security-implication layer:

• Step-by-step traces of how the agent chained the Jolt and Dory weaknesses into a forged proof path.
• Code-level explanation of the Fiat-Shamir ordering observation and why it was not exploitable on its own.
• Detailed walk-through of the Dory binding gap and the alternate opening point the agent used to satisfy the final proof.
• The exact program and verifier behaviour used to demonstrate a false accepted output.

👉 The full VERIA LABS post covers the proof chain, dependency failure, and end-to-end exploit path.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners translate identity principles into stronger control decisions across complex systems and delegated trust chains.