Pith. sign in

REVIEW 5 major objections 5 minor 29 references

NiyamAI - An Intent-Bound AI Agent with Cryptographically Verifiable Guardrails using Zero-Knowledge Proofs

T0 review · 5 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper claims that AI-agent tool calls can be gated by a zero-knowledge proof, so that external parties can verify a safety check happened before any action executes, without trusting or seeing the Judge model's weights.

desk verdict The architecture is plausible and the paper is unusually honest about its benchmark adaptation, but the ZK proof is demonstrated on a different, unmeasured model than the one that gets the 88.5% F1, so the central claim is not supported as written. read the letter →

arxiv 2608.07167 v1 pith:JVFFSW4D submitted 2026-08-07 cs.AI

Aditya Katkar , Om Karkele , Kartik Mandhane , Manisha More , Yash Kashid This is my paper · ORCID
classification cs.AI
keywords AIagentsafetyzero-knowledgeproofszk-SNARKintentcontracttoolcallguardrailverifiablemachinelearningpromptinjectiondefenseauditability
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Niyam-AI aims to replace 'trust us' in AI-agent safety with a cryptographic receipt. It seals the agent's permitted tools and constraints into an immutable SHA-256-based Intent Contract at session start, then intercepts every proposed tool call and runs it through a small deterministic Judge model. Only when the Judge says Safe does the system generate a zero-knowledge proof, and the tool executes only after that proof verifies. On 2,000 real-world agent scenarios, the paper reports an F1 score of 88.5% with a 1.1% false-positive rate, beating three existing guardrail tools, with proof verification taking roughly 53 ms. The authors are explicit that this reflects a classifier adapted to the benchmark's distribution compared with fully zero-shot baselines.

What carries the argument

The central mechanism is the Intent-Bound Execution protocol: an immutable Intent Contract hashed to H_I, an ActionHash H_a, a lightweight deterministic Judge model as the binary safety oracle, and a zk-SNARK compiled from the Judge's exported network into a verifiable circuit. The load-bearing design choice is proving only the small Judge model, not the full language model, which keeps proof generation near 2.26 seconds while verification takes about 53 ms and requires no access to model weights. The proof is what carries the argument: it converts a software check that could be bypassed or silently skipped into a publicly verifiable computation.

What would settle it

Locate any scenario from the benchmark's 'Produce unsafe information/misinformation' category that the Judge labels Safe but that genuinely violates the declared intent—the paper's own category-level accuracy of 92.0% implies such cases exist—and run it through the pipeline. If the tool executes with a valid proof, then the end-to-end guarantee is shown to certify only the Judge's computation, not the action's actual safety.

Watch

Extended reading notes

Core claim

The central claim is that safety enforcement for tool-calling agents can be made both accurate and independently checkable by separating the safety decision from the agent itself. Concretely, the system defines a session Intent Contract I, commits it as H_I = SHA-256(I), computes an ActionHash H_a = SHA-256(a) for each proposed action, and has a deterministic Judge network J map the pair (H_I, H_a) to Safe or Unsafe. A zk-SNARK proves knowledge of the Judge's weights and inference trace such that J(x, w) = 1 for the public tuple x = (H_I, H_a), and the execution rule is Execute(a) if and only if Verify(vk, π, x) = 1. Theorem 1 states that, with collision-resistant SHA-256 and a knowledge-sound zk-SNARK, no adversary can cause an action to execute when J(x, w) = 0. The contribution is therefore not a claim that the Judge is infallible—the paper reports imperfect recall—but that enforcement of the Judge's decision is cryptographically auditable after the fact.

Load-bearing premise

The load-bearing premise is that the Judge model's Safe verdict is a correct and complete test of whether the action truly honors the intent contract; the cryptography only proves that the Judge made that call, not that the call was right.

Editorial extensions

If this is right

  • Every executed tool call in a Niyam-AI deployment is accompanied by a proof that a third party can verify in milliseconds, so compliance and audit trails no longer depend on trusting the host machine.
  • An append-only log of hashes and proofs makes tampering detectable: altering the Intent Contract mid-session changes H_I and causes proof verification to fail.
  • The verifier can run locally or be exposed as a smart contract, enabling decentralized or cross-organization verification of agent behavior.
  • Because proof generation adds about 2.26 seconds per approved action, the framework suits high-stakes, low-frequency actions such as irreversible system changes, while latency-sensitive workloads would require batching or hardware acceleration.
  • Token-level constrained decoding and this proof-verified semantic gate are complementary: one enforces syntactic form, the other verifies that a fully formed tool call honors the session's declared intent.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the Judge's binary verdict is the real bottleneck, the same architecture could be extended to attest richer policy outputs—such as a reason code or confidence score—without changing the proving layer; the correctness question would then shift from cryptography to the specification and training of the Judge.
  • A direct stress test of the semantic layer would be to evaluate the Judge on an out-of-distribution corpus with none of the benchmark's phrasing conventions; a sharp accuracy drop would show that the verifiable guarantee is computation integrity, not general safety.
  • Third-party verifiability does not by itself tell a verifier which Judge weights were used; two different Judges could issue opposite verdicts for the same hash pair, so the audit trail attests to a particular policy's execution, not to the policy's correctness.
  • One could instrument the pipeline to emit the Judge's full decision trace as public auxiliary data, allowing post-hoc analysis of which input features drove a Safe verdict and giving external auditors a way to probe for learned keyword shortcuts.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 5 minor

Summary. The paper proposes Niyam-AI, a guardrail architecture for LLM agents in which an Intent Contract is committed via SHA-256, tool calls are intercepted and classified by a lightweight Judge model, and a zk-SNARK proof of the Judge's Safe decision is generated with EZKL before execution. The authors evaluate the approach on 2,000 Agent-SafetyBench scenarios, report a 5-fold out-of-fold F1 of 88.5% with a 1.1% false-positive rate, compare against NeMo Guardrails, Llama Prompt Guard 2, and GPT-OSS-Safeguard, and report proof-generation and verification latencies of about 2.26 s and 53 ms. The paper includes an explicit methodological caveat in Section IV.C that the Judge is adapted to Agent-SafetyBench while the baselines are zero-shot, and an open-science appendix with code and evaluation artifacts.

Significance. The core idea—binding an agent's tool-use permissions to a cryptographic commitment and proving the execution of a small safety classifier with a zk-SNARK—is timely and potentially useful as a practical ZKML application. The paper also has genuine strengths: out-of-fold cross-validation reduces the risk of per-scenario leakage, bootstrap confidence intervals and McNemar's exact test are appropriate, the adversarial red-team section reports discovered vulnerabilities and fixes, and Appendix A promises reproducible artifacts. However, the manuscript does not currently demonstrate that the system that is accurate is the same system that is ZK-verifiable, and the formal protocol does not connect cleanly to the classifiers actually evaluated. The headline claim 'highly accurate and mathematically verifiable' is therefore not supported for any single configuration. The comparison against zero-shot baselines is honestly disclosed but still makes the reported accuracy margin difficult to interpret as evidence of architectural superiority.

major comments (5)
  1. [Section III.D, Table I, Table V] The formal protocol defines the Judge input as the 512-bit tuple (IntentHash, ActionHash), but the classifier whose F1 is reported in Tables IV and V is a 3000-dim TF-IDF logistic regression, while the model compiled into the EZKL circuit in Table III is an 11-dim → 8 → 2 PyTorch network. The paper never specifies how the hash tuple is mapped to either feature representation, nor does it explain which Judge is used in the 'Full Niyam AI' row of Table V. Since that row reports metrics identical to 'Gate + Judge', the paper implicitly assumes the ZK layer proves the same classifier whose accuracy is measured, but Table I states the primary classifier's export format is 'N/A (not ZK-proved directly)'. The central claim that Niyam-AI is both highly accurate and mathematically verifiable is therefore not established for any single system.
  2. [Section IV.C, Section VI, Table IV] The empirical comparison is between a classifier trained on Agent-SafetyBench's distribution (using out-of-fold predictions) and baselines that are evaluated fully zero-shot. The authors disclose this asymmetry in Section IV.C, and the abstract contains a partial caveat, but Section VI's conclusion restates the result as 'outperformed three established safety systems' without that caveat. Under the reported design, the F1 margin is expected to be large because the Judge has learned the benchmark's vocabulary and phrasing, so the result does not support a claim of inherent architectural superiority. The conclusion and abstract should either be restricted to 'a domain-adapted classifier evaluated against zero-shot baselines' or supported by an additional out-of-distribution evaluation.
  3. [Section III.D, Theorem 1, Section 1] Theorem 1 proves only that no adversary can cause execution of an action with J(x,w)=0; it does not prove that J(x,w)=1 implies the action is actually safe. The equivalence J(x,w)=1 ⟺ action satisfies intent constraints is an assumption about the Judge's correctness, not a proven property. The Introduction's statement that 'the proof only certifies that a lightweight Judge model made the right call' is therefore overclaimed: the zk-SNARK certifies the Judge's computation, not the semantic correctness of the decision. This limitation should be stated formally as an assumption, and the paper's language should distinguish between 'the Judge classified the action as Safe' and 'the action is Safe'.
  4. [Section IV.F, Table V, Section V.D, Table X] Several quantitative results are internally inconsistent. In Section IV.F, the text says adding the Judge raises F1 from 0% to 91.6% and that the full pipeline also yields 91.6%, but Table V reports Gate Only F1 as 74.0%, Gate + Judge as 88.5%, and Full Niyam AI as 88.5%. The text also attributes 295.6 ms of additional latency to the ZK layer, while Table V reports 2,260.6 ms. In Section V.D, the text describes 12 adversarial vectors across five classes with 9/12 protected before fixes and 12/12 after, but Table X lists six classes and 18 vectors with 15/18 before and 18/18 after. These contradictions make the ablation and adversarial-robustness claims unreliable as reported and must be corrected or reconciled.
  5. [Section III.C, Section III.D, Section IV.A, Table I] There is a mismatch between the described execution path and the implemented classifiers. Section III.C says the interception module feeds the (IntentHash, ActionHash) tuple into a Judge Neural Network implemented in PyTorch, and Section IV.A repeats that the Judge is implemented in PyTorch and exported to ONNX. Table I, however, identifies the primary classifier used for the headline results as a scikit-learn TF-IDF logistic regression, with the PyTorch model serving only as a ZK circuit compilation demo. The paper needs to specify which model is actually in the execution path, how its features are derived from the cryptographic commitments, and how the ZK circuit binds to those features. Without this, the cryptographic binding between the Intent Contract and the evaluated classifier is not demonstrated.
minor comments (5)
  1. [Abstract, Table VII] The abstract reports McNemar win counts of 390/20, 115/13, and 384/19, while Table VII reports 387/20, 112/13, and 381/19; these numbers should be harmonized.
  2. [Abstract, Table III] Proof-generation and verification times differ between the abstract (2260.6 ± 218.4 ms and 53.1 ± 11.8 ms) and Table III (2160.4 ± 510.6 ms and 65.3 ± 18.8 ms); the paper should state which measurement is the headline result and why the values differ.
  3. [Appendix A] Appendix A refers to the bootstrap table as Table VIII and the McNemar table as Table IX, but these correspond to Tables VI and VII in the main text; the cross-references should be corrected.
  4. [Table V] The standard deviation for the Full Niyam AI latency is printed as '2196.1029' without units and with an implausible number of decimal places; the associated text also gives a different value of 295.6 ms, so the latency reporting needs to be cleaned up.
  5. [Section IV.F] The text says the allowlist alone achieves an F1 of 0%, but Table V reports 74.0% for Gate Only; if this is a typo, it should be fixed because it obscures the ablation's message.

Circularity Check

2 steps flagged · score 6.0 of 10

Niyam-AI's headline 'highly accurate and mathematically verifiable' is partly circular: the 88.5% F1 is an in-distribution fit on Agent-SafetyBench (conceded in IV.C), and Theorem 1's soundness guarantee is true by the definition of J as the safety oracle, not by a proof that J is actually correct.

  1. fitted input called prediction [Section IV.C (Security Enforcement Evaluation); Table IV note]
    "Niyam-AI's classifier is fitted to Agent-SafetyBench's specific scenario distribution and phrasing conventions across all five cross-validation folds — no scenario's own out-of-fold prediction reflects information seen during its own training fold, which rules out leakage in the strict sense, but the classifier has still learned the general vocabulary and structural patterns common to ASB-style instructions. The three baselines (NeMo, Llama Prompt Guard 2, GPT-OSS-Safeguard) are evaluated fully zero-shot: none has been trained or fine-tuned on any ASB-style text in any form."

    The F1 of 88.5% is not a prediction from an untrained system; it is the cross-validated accuracy of a classifier whose training folds all come from Agent-SafetyBench, so the model has adapted to the benchmark's scenario distribution and phrasing before being scored on the held-out fold. The three baselines were never allowed this adaptation, yet Section IV.C itself labels the comparison 'a domain-adapted classifier evaluated against general-purpose zero-shot safety models.' The headline margin is therefore produced by the fitting procedure, not by an architectural property; the paper's own caveat concedes the result is not evidence of inherent accuracy independent of adaptation.

  2. self definitional [Section III.D.4 (Judge Function) and Section III.E (Theorem 1)]
    "We model the safety classifier as a deterministic function 𝐽 that evaluates whether a proposed action complies with the immutable session intent. ... 𝐽(𝑥, 𝑤) = 1 ⟺ action 𝑎 satisfies intent constraints ... If SHA-256 is collision-resistant and the zk-SNARK system satisfies knowledge soundness, then no adversary can cause execution of an action 𝑎 such that 𝐽(𝑥, 𝑤) = 0 without breaking underlying cryptographic assumptions."

    The theorem is a restatement of the protocol plus the definition of J. Because J is stipulated to be 1 exactly when the action satisfies the intent constraints, the set 'actions with J(x,w)=0' is, by definition, the set of contract violations, and Algorithm 1 already blocks those at step 6 before any proof is generated. The zk-SNARK only attests that the Judge function computed 1; it cannot attest that the Judge's verdict matches real-world safety. Table VIII reports J's accuracy as 92.0% on one category, so the iff definition is an empirical assumption, not a proven equivalence. The claimed 'soundness of execution control' therefore reduces to trusting the fitted Judge rather than to a cryptographic derivation of safety.

full rationale

The paper's genuinely non-circular core is the ZK-ML enforcement layer: compiling an ONNX Judge model into an EZKL/Groth16 circuit so a third party can verify that a specific Judge computation occurred is a self-contained engineering result whose validity rests on external cryptographic assumptions, not on the paper's own fitted values. There are no author self-citations, no imported uniqueness theorems, and no ansatz smuggled in via citation. The circularity is in the packaging of that layer with the benchmark claim. First, the 'prediction' of 88.5% F1 is a fitted, in-distribution evaluation: the Judge was trained on Agent-SafetyBench's distribution in every fold and scored on held-out folds, while all baselines were zero-shot; the paper itself says the classifier 'has still learned the general vocabulary and structural patterns common to ASB-style instructions' and instructs readers not to read the margin as evidence of an inherent architecture advantage. Second, Theorem 1's soundness is definitional: J is declared to be 1 iff the action satisfies the intent contract, so proving that actions with J(x,w)=0 cannot execute is a direct consequence of the protocol's own block-if-zero rule, not an independent mathematical guarantee that the action is safe in the world; the ZK proof certifies only that the Judge said 'Safe.' The paper's own category-level accuracy (92.0% for one misinformation category, 1.1% FPR) shows J is not a perfect oracle, so the iff definition is an unverified premise. A further evidentiary gap, noted in the paper's Table I, is that the 88.5%-accurate scikit-learn classifier is explicitly 'not ZK-proved directly,' while the ZK circuit is compiled from a different PyTorch model whose accuracy is never reported; the abstract's conjunction 'both highly accurate and mathematically verifiable' is therefore not instantiated by a single configuration. These issues are partly mitigated by the paper's unusual candor: the abstract and Section IV.C disclose the adaptation asymmetry, Section IV.E says 'we don't want to oversell' the accuracy, and the future-work section calls for independent out-of-distribution testing. What remains is not a fabricated or hidden circularity, but a genuine partial one: the accuracy headline reduces to the fitting procedure, and the verifiability headline's soundness theorem reduces to the definition of J.

Assumptions & free parameters 5 free parameters · 5 assumptions · 1 invented entities

The central claim rests on standard cryptographic assumptions (collision resistance, knowledge soundness), a trained classifier whose weights are fit to the evaluation benchmark, and an unvalidated labeling function that produces the training labels. The ZK proof itself is only demonstrated on a small separate network, not the evaluated classifier.

free parameters (5)
  • Judge model weights (logistic regression) = Not disclosed (3000 TF-IDF features, lbfgs solver)
    The primary classifier's parameters are fit to Agent-SafetyBench in each CV fold; the F1 result measures this fit.
  • 11 hand-engineered features = Unspecified
    These features are used as input to the Judge but are not enumerated in the paper, so their construction is an unmeasured modeling choice.
  • Ground-truth labeling function for Agent-SafetyBench = Derived labeling, not shown
    The mapping from ASB instructions to intent-violation labels is a non-trivial choice that determines all subsequent accuracy numbers; the function is said to be included in code but is not described.
  • TF-IDF dimensionality (3000) = 3000
    Chosen by hand; affects classifier behavior.
  • ZK demo model architecture (11-8-2) = 11 inputs, 8 hidden, 2 outputs
    This tiny network is the only model actually compiled into a ZK circuit; its hyperparameters are arbitrary.
assumptions (5)
  • domain assumption SHA-256 is collision-resistant
    Relied on for IntentHash binding in Section III.A and Theorem 1.
  • domain assumption Groth16 zk-SNARK satisfies knowledge soundness
    Required for Theorem 1 in Section III.E.
  • ad hoc to paper The Judge model is a correct and complete safety oracle
    The entire safety guarantee reduces to J(x)=1 implying a is safe; this is assumed, not proven, and the paper's own category results and FPR show the Judge makes errors.
  • domain assumption Agent-SafetyBench labels are a valid ground truth for agent safety
    The evaluation assumes the benchmark's instruction-to-harm mapping is correct and representative.
  • ad hoc to paper The derived labeling function correctly maps ASB instructions to intent violations
    Authors-created labeling function is a hidden step that produces the training labels; no validation of this mapping is provided.
invented entities (1)
  • Intent Contract / IntentHash independent evidence
    purpose: A SHA-256 commitment binding session-level permitted tools and constraints, used as public input to the verification protocol.
    The hash is checkable by anyone who has the contract JSON and the SHA-256 algorithm, so it has an external falsifiable handle; but it is a data structure, not a new physical entity.

how reviews work

0 comments
Cite this review

Pith. "Pith review of NiyamAI - An Intent-Bound AI Agent with Cryptographically Verifiable Guardrails using Zero-Knowledge Proofs." pith.science (2026). https://pith.science/paper/JVFFSW4D

@misc{pith2026260807167,
  author       = {Pith},
  title        = {Pith review of: NiyamAI - An Intent-Bound AI Agent with Cryptographically Verifiable Guardrails using Zero-Knowledge Proofs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JVFFSW4D}},
  note         = {Machine review of arXiv:2608.07167}
}
read the original abstract

Giving an AI agent the ability to send emails, query databases, or execute commands is useful--until the agent is tricked into doing something it shouldn't. Prompt injection, hallucinated reasoning, and unsafe tool calls form the primary attack surface for autonomous LLM agents. Existing defenses rely on software checks like system prompts or policy filters running on the same machine the attacker targets, offering no verifiable proof of execution. We introduce Niyam-AI, a framework that makes safety enforcement provable. At session start, permitted tools and constraints are locked into an Intent Contract committed via SHA-256. Every tool call is intercepted and validated by an isolated Judge model; upon passing, a zk-SNARK proof is generated via EZKL. The tool executes only after proof verification, allowing third parties to confirm enforcement without accessing Judge model weights. Evaluating Niyam-AI on 2,000 real-world scenarios from Agent-SafetyBench against NeMo Guardrails, Meta's Llama Prompt Guard 2, and OpenAI's GPT-OSS-Safeguard using 5-fold stratified cross-validation yields an F1 score of 88.5% with a 1.1% false-positive rate (bootstrap 95% CI: [85.19%, 91.88%], N=1000). McNemar's exact paired test confirms significant improvement: Niyam-AI wins 390 discordant scenarios against NeMo (vs 20 losses), 115 against Prompt Guard 2 (vs 13), and 384 against GPT-OSS-Safeguard (vs 19) with p < 0.0001 in all cases. Proof generation adds 2260.6 +/- 218.4 ms per approved action, while verification takes 53.1 +/- 11.8 ms. Niyam-AI provides a guardrail that is both highly accurate and mathematically verifiable--though this reflects a classifier adapted to Agent-SafetyBench evaluated against zero-shot baselines, a distinction discussed in Section IV.C.

Figures

Figures reproduced from arXiv: 2608.07167 by the authors.

Figure 2
Figure 2. The cryptographic sealing mechanism generating the immutable IntentHash. B. The Operation Layer (Local execution) The operation layer is responsible for processing user inputs and generating proposed actions using localized, fine-tuning large language models. Unlike standard implementation that rely on high level agentic frameworks like LangChain framework [12] to manage the continuous loop of reasoning, planning, a… view at source ↗
Figure 1
Figure 1. High-level system architecture of Niyam-AI. A. Intent Binding and Cryptographic Sealing The basis for Niyam-AI is the definition of the "Intent Contract" that is immutable and defined during initialization of the agent session. In contrast to the conventional prompt [15] which is vulnerable to context window tampering and prompt injection attacks, the Intent Contract is defined in a structured JSON format, listing t… view at source ↗
Figure 3
Figure 3. Flowchart detailing the interception, hashing, and evaluation pipeline for AI tool execution. The Guardrail Layer acts as the security middleware. It utilizes a lightweight neural-network-based classification engine that evaluates the ActionHash against the IntentHash [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Low-level Zero-Knowledge Machine Learning pipeline utilizing EZKL for verifiable inference. H. Verification and Execution Enforcement The final component is the Verification Layer. Before the execution engine invokes the requested tool (e.g., executing a database query…
Figure 5
Figure 5. Figure 5: UML Sequence Diagram illustrating the cryptographic handshake and verification lifecycle between the Agent, Judge, and Verifier. Only if the mathematical verification returns TRUE does the execution engine finalize the action. All verified actions, along with their cor…
Figure 8
Figure 8. Figure 8: Forbidden Tool Detection and Security Alert [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]
Figure 6
Figure 6. Figure 6: Niyam-AI Governed Execution Console [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: depicts the proof generation and verification process in Niyam-AI. Before a tool action is executed, the generated proof is verified to confirm compliance with the defined policy [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

29 extracted references · 14 canonical work pages

  1. [1]

    Verifiable evaluations of machine learning models using zkSNARKs,

    T. South, A. Camuto, S. Jain, S. Nguyen, R. Mahari, C. Paquin, J. Morton, and A. Pentland, “Verifiable evaluations of machine learning models using zkSNARKs,” arXiv preprint arXiv:2402.02675, 2024. Available: https://arxiv.org/abs/2402.02675

    arXiv 2024

  2. [2]

    vCNN: Verifiable Convolutional Neural Network Based on zk-SNARKs,

    S. Lee, H. Ko, J. Kim, and H. Oh, “vCNN: Verifiable Convolutional Neural Network Based on zk-SNARKs,” IEEE Trans. Dependable Secure Comput., vol. 21, no. 4, pp. 4254– 4270, 2024. doi: 10.1109/TDSC.2023.3348760

    arXiv 2024

  3. [3]

    ValidCNN: A Large -Scale CNN Predictive Integrity Verification Scheme Based on zk -SNARK,

    Y. Fan, K. Ma, L. Zhang, X. Lei, G. Xu, and G. Tan, “ValidCNN: A Large -Scale CNN Predictive Integrity Verification Scheme Based on zk -SNARK,” IEEE Trans. Dependable Secure Comput., 2024. doi: 10.1109/TDSC.2024.3371643

    work page arXiv 2024

  4. [4]

    Zero-Knowledge Proof-Based Verifiable Decentralized Machine Learning in Communication Network: A Comprehensive Survey,

    Y. Zhang et al., “Zero-Knowledge Proof-Based Verifiable Decentralized Machine Learning in Communication Network: A Comprehensive Survey,” arXiv preprint arXiv:2310.14848, 2023

    arXiv 2023

  5. [5]

    Proofs, Arguments, and Zero -Knowledge,

    J. Thaler, “Proofs, Arguments, and Zero -Knowledge,” Foundations and Trends® in Theoretical Computer Science, vol. 14, no. 2, 2020. doi: 10.1561/0400000086

    doi:10.1561/0400000086 2020

  6. [6]

    The Knowledge Complexity of Interactive Proof Systems,

    S. Goldwasser, S. Micali, and C. Rackoff, “The Knowledge Complexity of Interactive Proof Systems,” Proc. 17th ACM STOC, 1985. doi: 10.1145/22145.22178

    arXiv 1985

  7. [7]

    Delegating Computation: Interactive Proofs for Muggles,

    S. Goldwasser, Y. Kalai, and G. Rothblum, “Delegating Computation: Interactive Proofs for Muggles,” Proc. 40th ACM STOC, 2008. doi: 10.1145/1374376.1374407

    arXiv 2008

  8. [8]

    On the Size of Pairing -Based Non-Interactive Arguments,

    J. Groth, “On the Size of Pairing -Based Non-Interactive Arguments,” EUROCRYPT, 2016. doi: 10.1007/978 -3-662- 49896-5_14

    doi:10.1007/978 2016

Show all 29 references
  1. [9]

    How to Prove Yourself: Practical Solutions to Identification and Signature Problems,

    A. Fiat and A. Shamir, “How to Prove Yourself: Practical Solutions to Identification and Signature Problems,” CRYPTO, 1986. doi: 10.1007/3-540-47721-7_12

    1986 doi

  2. [10]

    Secure Hash Standard (SHA-256),

    National Institute of Standards and Technology (NIST), “Secure Hash Standard (SHA-256),” FIPS PUB 180-4, 2015. doi: 10.6028/NIST.FIPS.180-4

    2015 doi

  3. [11]

    The EZKL System,

    EZKL Contributors, “The EZKL System,” Official Documentation, 2024. Available: https://docs.ezkl.xyz/

    2024

  4. [12]

    LangChain: Building applications with LLMs through composability,

    H. Chase et al., “LangChain: Building applications with LLMs through composability,” Official Documentation,

  5. [13]

    Toolformer: Language Models Can Teach Themselves to Use Tools,

    T. Schick et al., “Toolformer: Language Models Can Teach Themselves to Use Tools,” arXiv preprint arXiv:2302.04761, 2023

    2023 arXiv

  6. [14]

    A Survey on Large Language Model based Autonomous Agents,

    L. Wang et al., “A Survey on Large Language Model based Autonomous Agents,” Frontiers of Computer Science, https://doi.org/10.48550/arXiv.2308.11432

    doi arXiv

  7. [15]

    Prompt Injection Attacks Against Large Language Model Applications,

    Y. Liu et al., “Prompt Injection Attacks Against Large Language Model Applications,” arXiv preprint arXiv:2306.05499, 2023

    2023 arXiv

  8. [16]

    The Attacker Moves Second: Stronger Adaptive Attacks Bypass Defenses Against LLM Jailbreaks,

    M. Nasr, N. Carlini, C. Sitawarin, et al., “The Attacker Moves Second: Stronger Adaptive Attacks Bypass Defenses Against LLM Jailbreaks,” arXiv preprint arXiv:2510.09023, 2025

    2025 arXiv

  9. [17]

    Constitutional AI: Harmlessness from AI Feedback,

    Y. Bai et al., “Constitutional AI: Harmlessness from AI Feedback,” arXiv preprint arXiv:2212.08073, 2022

    2022 arXiv

  10. [18]

    OWASP Top 10 for Large Language Model Applications,

    OWASP Foundation, “OWASP Top 10 for Large Language Model Applications,” 2025. Available: https://owasp.org/www-project-top-10-for-large-language- model-applications/

    2025

  11. [19]

    AI Risk Management Framework (AI RMF 1.0),

    NIST, “AI Risk Management Framework (AI RMF 1.0),” 2023. Available: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf

    2023

  12. [20]

    Artificial Intelligence Management System,

    ISO/IEC 42001:2023, “Artificial Intelligence Management System,” 2023

    2023

  13. [21]

    Ethereum White Paper,

    V. Buterin, “Ethereum White Paper,” 2013

    2013

  14. [22]

    SNARKs for C: Verifying Program Executions Succinctly and in Zero Knowledge,

    A. Ben -Sasson et al., “SNARKs for C: Verifying Program Executions Succinctly and in Zero Knowledge,” CRYPTO, 2013. Available https://eprint.iacr.org/2013/507.pdf

    2013

  15. [23]

    NeMo Guardrails: A Toolkit for Controllable and Safe LLM Applications with Programmable Rails,

    NVIDIA Corporation, "NeMo Guardrails: A Toolkit for Controllable and Safe LLM Applications with Programmable Rails," arXiv preprint arXiv:2310.10501, 2023. Available: https://arxiv.org/abs/2310.10501 APPENDIX A — OPEN SCIENCE APPENDIX This paper’s core contributions are evalua...

    2023 arXiv

  16. [25]

    Source code. The complete Niyam-AI implementation — Intent Contract sealing, the Tool Authority Gate, the Judge model (both the primary scikit-learn classifier used for Table IV/V and the secondary PyTorch model used for the EZKL circuit in Table III), the control -flow sessio...

  17. [26]

    Evaluation scripts. All scripts used to produce every table in this paper are included: 5 -fold cross-validated evaluation (Table IV), ablation study (Table V), bootstrap confidence intervals (Table VIII), McNemar’s significance test (Table IX), and the 12 -vector adversarial ...

  18. [27]

    Baseline predictions. Raw per-scenario prediction CSVs for all three baselines (NeMo Guardrails, Llama Prompt Guard 2, GPT-OSS-Safeguard-20B) are included, so Table IV and Table IX can be independently reproduced without re - running the baseline models

  19. [28]

    Dataset. We evaluate on the public Agent -SafetyBench dataset (thu-coai, 2024), which is not our own artifact but is cited and linked; our derived ground -truth labeling function (mapping instructions to intent-violation labels) is included as source code

    2024

  20. [29]

    EZKL circuit artifacts. The compiled ZK circuit, proving/verification keys, and a sample proof.json demonstrating a real, independently verifiable zk -SNARK proof are included, along with the exact EZKL 23.0.5 pipeline commands (gen_settings, calibrate_settings, compile_circui...

    2024

  21. [2024]

    Available: https://python.langchain.com/

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.