This is a submission for the Hermes Agent Challenge
There's something quietly broken at the heart of agentic AI systems right now.
I noticed it while building ZKAuth — a Zero-Knowledge Proof identity system for Android that I developed as my final-year project. I was deep in Plonky2 circuits, JNI bridges, and NFC passport reads when it hit me: we're building incredibly capable AI agents that can plan, reason, and execute multi-step tasks autonomously — but almost none of them have a meaningful answer to the question: who authorized this?
Hermes Agent is a great example of where agentic AI is heading. Open source, self-hosted, capable of tool use and multi-step reasoning. It's genuinely impressive. But like most agent systems today, identity is an afterthought — if it's a thought at all. The agent runs. It executes. It acts on behalf of someone. But that "someone" is largely taken on faith.
That's the gap I want to talk about.
The Identity Problem in Agentic Systems
When you give an AI agent access to tools — file systems, APIs, databases, communication channels — you're making an implicit trust decision. You're saying: the entity that triggered this agent is who they claim to be, and they are authorized to do what this agent is about to do.
Traditional systems handle this with passwords, OAuth tokens, session cookies. These work reasonably well for human-facing interfaces. But agentic workflows break the assumption. An agent might:
- Chain multiple tool calls across different services
- Run in the background long after the initial trigger
- Act on behalf of a user without that user being present in the loop
- Operate in environments where the "user" is itself another agent
In each of these cases, a stolen token or a compromised session is catastrophic — not just for one action, but for the entire chain of actions the agent takes. You don't just lose one API call. You lose the whole workflow.
And in high-stakes contexts — financial transactions, medical records, legal documents, government services — this isn't a theoretical risk. It's a design flaw waiting to be exploited.
What Zero-Knowledge Proofs Actually Are (Without the Math Lecture)
I'll spare you the elliptic curve deep dive. Here's the intuition:
A Zero-Knowledge Proof lets you prove something is true without revealing why it's true.
Classic example: I can prove to you that I know the password to a vault without ever telling you the password. You gain certainty. I reveal nothing.
Applied to identity: I can prove that I am over 18, that I am a registered citizen, that I hold a valid credential — without revealing my date of birth, my ID number, or any raw personal data. The verifier gets a cryptographic guarantee. The prover retains privacy.
This is exactly what identity in agentic systems needs. Not "here is my token, trust me." But "here is a cryptographic proof that I am authorized, verifiable without a central authority, and revealing nothing beyond what the task requires."
ZKAuth: What I Built and What I Learned
ZKAuth started as my final-year thesis at Hazara University, Pakistan. The goal was simple in concept and brutal in execution: build a working ZK identity system that runs on an ordinary Android phone, with no cloud dependency for proof generation.
The stack ended up being:
- Rust + Plonky2 for the ZK proof engine (compiled to native ARM via NDK)
- Kotlin + Jetpack Compose for the Android frontend
- JNI bridge connecting the Rust engine to the Android layer
- NFC reader for ICAO 9303-compliant passport reading
- Node.js relay deployed on Railway for the verification backend
The hardest part wasn't the cryptography. It was the JNI layer — getting Rust's memory model to cooperate with Android's JVM across a foreign function interface, while keeping ProGuard from stripping the native class names during R8 minification. I spent more time on that than on the actual ZK circuits.
But the result was worth it. On a Realme RMX3830 — a mid-range device running Android 14 on aarch64 — ZKAuth generates a Plonky2 proof in 39 milliseconds and verifies in 8 milliseconds. For context, Polygon's reference implementation on a MacBook Pro clocks in at around 170ms. Mobile, mid-range, faster.
The security model is what matters most for the agent use case though. ZKAuth never stores raw identity data. What gets stored is a SHA-256 commitment. What gets transmitted is a ZK proof. What the verifier receives is a cryptographic guarantee — not a password, not a token, not a session cookie that can be stolen and replayed.
ECDSA-signed QR codes with anti-replay timestamps. Android KeyStore biometric binding. HKDF/Argon2id key derivation. The system was designed from the ground up so that even if the relay server is fully compromised, there is nothing there worth stealing.
The Integration Vision: Hermes Agent + ZK Identity
Here's where it gets genuinely interesting for the Hermes Agent ecosystem.
Imagine an agentic workflow where before Hermes Agent executes any sensitive tool call — a file write, a financial API call, a message sent on someone's behalf — it first requests a ZK identity proof from the user. The proof is generated locally on the user's device, transmitted to the agent, and verified against a commitment stored at setup time.
The agent never sees the user's credentials. It never holds a token that can be replayed. It gets a one-time cryptographic proof tied to the specific action being authorized. If the proof is valid, execution proceeds. If not, the action is blocked.
This isn't science fiction. The primitives exist today. Plonky2 (and its successor Plonky3) can generate these proofs fast enough for interactive use. The Android KeyStore can bind proof generation to biometric authentication, so the user has to physically authorize each sensitive action. The JNI bridge to make this work on mobile is already built — in ZKAuth.
What's missing is the glue layer: a standardized way for agent frameworks like Hermes to request, receive, and verify ZK identity proofs as part of their tool-use pipeline. That's a protocol problem as much as an engineering problem, and it's one the open source community is well-positioned to solve.
A concrete starting point would be a ZK Identity MCP Server — a Model Context Protocol server that Hermes Agent can call to request identity proofs. The server acts as the interface between the agent's tool-use layer and the user's local ZKAuth instance. Rather than a single "I am this person" proof, you'd generate proofs scoped to specific actions: "I am authorized to execute this file write at this timestamp." Plonky2 circuits can encode this logic cleanly.
Why This Matters More in the Global South
I'm building this from Pakistan. That context matters.
In high-income countries, identity infrastructure is largely solved — imperfectly, but solved enough. Driver's licenses, passports, national ID cards, credit histories — these exist and are trusted.
In Pakistan, and across much of the Global South, the situation is different. Millions of people have no formal credit history. Government ID systems are centralized and not always trustworthy. Fintech platforms that could extend financial services to unbanked populations hesitate because they cannot reliably verify who they're serving without exposing those users to surveillance or data breach risk.
ZK identity changes this calculus. A user can prove they hold a valid government-issued document without that document's data ever leaving their device. An agentic financial service can verify a user's eligibility without storing sensitive records. The verification is as strong as the underlying credential, but the attack surface is near zero.
Agentic AI is coming to these markets whether the infrastructure is ready or not. Building ZK identity into agent systems from the start — rather than retrofitting it later — is the kind of decision that will determine whether these systems empower users or exploit them.
The Bigger Point
Open source AI agents are one of the most exciting developments in the current AI landscape. Hermes Agent, and systems like it, represent a genuine shift toward user-controlled, self-hosted intelligence. That's worth protecting.
But capability without accountability is a liability. An agent that can do anything, on behalf of anyone, with no cryptographic guarantee of authorization, is not a trustworthy system — no matter how good its reasoning is.
Zero-Knowledge Proofs are not the only answer. But they are a uniquely powerful one, because they offer verifiability without surveillance. You don't need to trust the agent, the relay server, or even the developer. You need to trust the math.
That's a foundation worth building on.
ZKAuth is an open source project. The IEEE paper covering the full architecture, threat model, and benchmark methodology is currently under review. If you're working on identity infrastructure for agentic systems and want to compare notes — find me on X at @hamidiqbal369.`
Top comments (0)