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

Introduction to the show: ident: Paper Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: Next we'll be talking about the paper "NiyamAI - An Intent-Bound AI Agent with Cryptographically Verifiable Guardrails using Zero-Knowledge Proofs".

Jane: The paper was written by Aditya Katkar, Om Karkele, Manisha More, Kartik Mandhane and Yash Kashid from Department of Computer Engineering, Vishwakarma Institute of Technology.

Tom: Stay tuned as we take you through the paper and discuss its implications.

Title: Tom: Good to have you with us. Today's paper comes out of Vishwakarma Institute of Technology in Pune. It's called "Niyameye — An Intent-Bound eye Agent with Cryptographically Verifiable Guardrails using Zero-Knowledge Proofs."

Jane: That's a dense title, but every piece earns its place. "Niyam" means rules or principles in Hindi and Sanskrit, which is a fitting name for a system whose entire job is binding an eye agent to its declared rules.

Tom: And "intent-bound" is really the thesis. Before the agent does anything, you lock in what it's allowed to do — which tools, what data scope, what limits — and that contract stays fixed for the whole session.

Jane: Then comes "cryptographically verifiable guardrails." Instead of hoping a safety filter does its job, you get a mathematical guarantee that it did. The zero-knowledge proof part is the tool that makes that guarantee possible while keeping the safety model private.

Lu: For listeners new to zero-knowledge proofs, the usual example is proving you know a password without ever revealing the password itself. Here, the system proves the safety check ran and passed without exposing the judge model's weights. It sounds exotic, but the underlying math has been around for decades.

Meng: That privacy piece matters. If verifying the check meant publishing the model that did the checking, you'd hand the attacker a perfect blueprint for getting around it.

Tom: The authors are five undergraduate computer engineering students from Vishwakarma Institute of Technology — Aditya Katkar, Om Karkele, Manisha More, Kartik Mandhane, and Yash Kashid. That's a student team building on some seriously heavy cryptographic machinery. And they're not just theorizing; they built a working prototype.

Lalam: And the broad implication reaches far beyond one demo. We're moving toward deployments where you don't trust the machine that ran the check — you trust the math instead. That changes who gets to audit eye. Any outside party can verify what happened without needing the company's internal infrastructure.

Jane: Right. Today, if an agent sends an email it shouldn't have, the vendor can only claim their filter should have caught it. With this approach, there's either a valid proof or there isn't. That's the whole shift in one sentence.

Tom: And that gap between "we checked" and "here's proof the check happened" is exactly the problem this paper goes after. Let's dig into how the pipeline actually works and what the measurements look like. I think listeners will be surprised by the latency numbers.

Summary: Jane: So the core idea is proof instead of promises. Walk us through the mechanics, Tom. Where does the whole thing start?

Tom: The system seals an Intent Contract at session start — a structured JSON file listing permitted tools, data scope, and operational limits. That gets hashed with SHA-256 into the IntentHash, and it stays constant for the whole session. Any change to the contract produces a hash mismatch, which blocks the action.

Jane: Then every tool call is intercepted before it reaches the operating system. The system hashes the tool name and arguments into an ActionHash and pairs it with the session's IntentHash. So you have two hashes — one for the rules, one for the proposed action.

Tom: That pair goes into a lightweight neural network called the Judge. If it says unsafe, the action is blocked and written to an append-only audit log. If it says safe, the system doesn't just trust the answer — it generates a zero-knowledge proof that the Judge actually ran and reached that conclusion.

Lu: And that's where EZKL comes in. It compiles the Judge model into a circuit that can be proven with a zk-SNARK, so a verifier can check the decision in about 53 milliseconds without ever seeing the model's weights.

Meng: The tool only executes after that proof checks out. So the safety decision and the tool execution are separated by a cryptographic handshake. If verification fails, execution is blocked and the failure gets logged too.

Jane: What did they measure? They ran 2,000 scenarios from Agent-SafetyBench and compared against three existing guardrail systems: NeMo Guardrails, Llama Prompt Guard 2, and GPT-OSS-Safeguard.

Tom: Their system came out with an F1 of 88 point 5 percent and a false-positive rate of just 1 point 1 percent. The strongest baseline, Llama Prompt Guard 2, reached 66 point 7 percent F1 with a 5 point 4 percent false-positive rate. NeMo Guardrails landed at 40 point 4 percent F1, blocking roughly one in five legitimate actions.

Lu: Wait — the false-positive rate of NeMo was 19 point 9 percent? That's terrible for real use.

Tom: Right, and the paper explains why: NeMo's self-check reacts to surface keywords like "email" or "execute" rather than actual intent. The framework's Judge is trained to recognize intent violations, not keywords. That's the difference between accurate and merely cautious.

Lalam: Step back — the entire approach hinges on proving a tiny model instead of a giant one. That choice is what turns the mathematics into something that runs in seconds rather than hours.

Jane: The other number that stands out is proof generation: about 2 point 26 seconds per approved action. The paper reports it as 2,260 point 6 milliseconds plus or minus about 218. That's the cost of the cryptographic guarantee.

Meng: And

Paper discussion segment 3: Tom: So, to recap in one breath: this paper shows you can lock an eye agent's permissions into a hash and attach a zero-knowledge proof to every safety check, so nobody has to trust the machine that made the call.

Jane: That's the core. But the authors are upfront that it's a first iteration, and the list of improvements they suggest is almost as interesting as what they built.

Tom: The biggest one is the binary judge. Right now it only says safe or unsafe. Real policies might need more nuance — like "allowed but require a second signature" or "allowed but only for amounts under a thousand."

Jane: And they know the two-second proof time is too slow for low-latency tasks. They mention hardware acceleration and batching as the obvious paths, which is promising because those are engineering problems, not research dead-ends.

Lu: That's a fair point. Their prototype ran on a laptop with an integrated GPU. Get this on even a modest accelerator and that 2 point 26 seconds could drop by an order of magnitude without changing the math.

Meng: For multi-agent setups they also flag a real gap: when one agent hands off to another, who owns the intent hash? That's going to need shared or delegated contracts, and it's genuinely unsolved.

Jane: Then there's the generalization issue. Their judge was trained on the same benchmark distribution it was evaluated on — even though they never saw the exact held-out scenarios, the vocabulary and structure were familiar.

Tom: Right, they're honest about that. They call it "domain-adapted" rather than a fair zero-shot win. So a real deployment would need the judge tuned to an organization's own tools and phrasing.

Lu: But the implications still feel big. Once you have a proof, the auditor doesn't need to be inside the company. A regulator, a customer, anyone can verify a safety decision in 53 milliseconds.

Meng: That flips the trust model. Instead of "believe our safety report," it becomes "here's the math, check it yourself." For industries like finance or healthcare, that could be transformative.

Jane: And their blockchain verifier on Ethereum Sepolia is the natural extension. Immutable audit logs plus cryptographic proofs — that's a governance layer we haven't really had before.

Tom: Makes you wonder, though — what happens when an attacker knows exactly what the judge is checking and builds a payload to game it? That might be the next conversation worth having.

Paper discussion segment 4: Tom: So, one-sentence recap: the paper's first page sets up the whole premise that agent safety needs to move from trusting software checks to proving they happened.

Jane: And what strikes me most about that first page is the way they frame the problem. They say most defenses live on the same machine the attacker is trying to compromise — a system prompt, a filter, a policy file. If that machine gets taken over, the check itself is gone, and there's no record that it ever existed.

Tom: Right, it's a trust gap. You might have the best guardrail in the world, but if the host is compromised, you can't tell whether it actually ran. The authors wanted a guarantee that doesn't depend on the platform being honest.

Jane: That's why they lock the agent's allowed tools and constraints into an "Intent Contract" hashed with SHA-256 at the start of a session. Then every tool call gets intercepted, checked against that hash by a small Judge model, and if it passes, they generate a zero-knowledge proof that the check really happened.

Tom: And the beautiful part of the zero-knowledge proof is that an outside party can verify the safety decision without ever seeing the Judge's weights. So you don't have to trust the company that runs the model — you just check the math.

Jane: Exactly. That's the "nobody has to take our word for it" line in the abstract. It's a completely different trust model than anything in the current guardrail ecosystem.

Tom: The first page also spells out their key engineering trick: they don't try to prove the entire multi-billion-parameter LLM made the right decision. They only prove the lightweight Judge model made the right call. That's what makes the whole thing computationally feasible.

Jane: It's a smart division of labor. The big model does the thinking, the small model does the policing, and the cryptography certifies the police officer's work.

Tom: Which brings up a natural question — what if the Judge itself has blind spots that an attacker can learn and exploit? That's probably a discussion worth having next.

Conclusion: Tom: One-sentence recap: Niyameye takes agent safety out of the trust-based realm and into the provable one, using an intent contract, a lightweight judge, and zero-knowledge proofs that anyone can verify.

Jane: It really is a shift in how we think about guardrails. Instead of asking a vendor to promise their filter worked, you ask for the proof — and the proof either checks out or it doesn't. That's a fundamentally different relationship between the people running eye and the people affected by it.

Tom: And the numbers back up the approach. Close to ninety percent F1 with a one percent false-positive rate, beating three established baselines. The two-second proof generation is a real cost, but for high-stakes actions like financial transactions or irreversible system changes, that delay is a bargain.

Jane: The authors were honest about the limits, too. Their judge is trained on the benchmark's distribution, not truly zero-shot. It doesn't handle content-based harm, only tool-call integrity. And multi-agent handoffs are still an open problem. So this is a solid proof of concept, not a finished product.

Tom: What excites me most is the auditable audit trail. Every approved action comes with a cryptographic artifact. Every blocked action is logged immutably. For regulators and enterprises, that turns "trust our safety team" into "here's the math, verify it yourself."

Jane: And the blockchain verifier on Ethereum Sepolia points to where this could go — decentralized oversight of autonomous agents without giving up proprietary model weights. That's a big deal for governance.

Tom: The team behind this is a group of undergraduates from Vishwakarma Institute of Technology in Pune. That's remarkable. They took cutting-edge cryptography and applied it to a practical problem with working code and open artifacts.

Jane: It sets a high bar for what a student project can accomplish. And it opens the door for more research into speeding up proof generation, hardening the judge against adversarial evasion, and scaling to multi-agent systems.

Tom: So we'll leave Niyameye here — a promising first step toward making agent safety something you can prove instead of something you hope for.

Jane: And speaking of attacks on agents, our next paper takes a hard look at exactly how those attacks work under real-world conditions. Stay tuned.