How I Built Gatekeeper-29k: A Verifiable Proof Gatekeeper Agent

Fauzi Darwis — Sun, 15 Nov 2026 12:36:30 +0000

How I Built Gatekeeper-29k: A Verifiable Proof Gatekeeper Agent

Agent Games by zkVerify is a competition where AI agents compete across four tracks for a 400,000 VFY prize pool. I entered the Proof Gatekeeper track, where an agent has to look at a task — a claimed zero-knowledge proof attached to a payment-like instruction — and decide, within 60 seconds, whether to APPROVE it or REJECT it. This is the story of building my agent, Gatekeeper-29k: the dead ends, the one bug that cost me an afternoon, and the honest limitation it still ships with.

What a Proof Gatekeeper actually decides

Every round, the platform dispatches tasks to my agent's public endpoint. Each task carries a Groth16 proof and a set of conditions: who the payment goes to, how much, and under what threshold. My agent has to verify the claim and return a decision. The traps it has to catch are specific:

VK substitution — the verification key has been swapped for a fake one.
Reused proof — a proof that was already used, replayed as if it were fresh.
Expired condition — the task's condition has already lapsed.
Recipient mismatch — the payment goes to the wrong address.
Amount overflow — the amount exceeds what the proof supports.
Threshold mismatch — the claimed threshold doesn't match the real one.
Valid — everything checks out, and the correct answer is APPROVE.

Get it right and the agent scores +12. Get it wrong and it loses points: −6 for a wrong APPROVE, −3 for a wrong REJECT. That asymmetry is the whole design tension of the track — approving something fraudulent is punished twice as hard as rejecting something legitimate, so a gatekeeper has to be careful in both directions, not just paranoid.

The first problem: my machine couldn't be reached from the internet

My agent runs on a Linux VM. The platform needs to call it at a public HTTPS URL, and the VM simply could not provide one:

Cloudflare Tunnel (trycloudflare) was blocked by the egress proxy — api.trycloudflare.com returned 403 / was sinkholed.
ngrok got further but never issued a URL: the tunnel session died on heartbeat timeout after about 25 seconds, twice, in two regions. The egress proxy kills the persistent control connection.
SSH reverse tunnels were reset by the gateway, and the VM has no public IP at all.

So the agent went serverless. The handler now lives on Vercel at https://agent-games-gatekeeper-rouge.vercel.app — a small endpoint that takes a signed task, runs the checks, and returns a decision. Before registration it passed 13 out of 13 live tests: valid tasks APPROVE, every trap type REJECTs with the correct reason, unsigned requests are refused, and the slowest decision took 0.5 seconds — far inside the 60-second limit.

The lesson is unglamorous but real: for an agent that only needs to answer requests, not hold a persistent connection, serverless is not a compromise. It was the only architecture that worked at all.

The 401 that wasn't an auth failure

Registration went through — agent name Gatekeeper-29k, registered on the dashboard — and then the platform's preflight check failed with "Agent returned HTTP 401". Twice.

The confusing part: my own signed test requests, using the exact HMAC secret the dashboard had issued, returned 200 every time, in all three signature encodings I tried (hex, sha256=, base64). The secret was right. The signature was right. And the platform still got a 401.

The difference turned out to be how the key itself is interpreted. The dashboard issues a 64-hex-character secret. My handler decoded it from hex into 32 raw bytes and used those bytes as the HMAC key. The platform, it turns out, signs with the raw UTF-8 bytes of the 64-character hex string itself — a 64-byte key that happens to look like hex, used as text.

Both sides were "correct" by their own reading of the same secret. The fix was to accept both interpretations: try verifying the signature with the hex-decoded bytes, and if that fails, try the raw UTF-8 bytes of the string — then sign the response with whichever key verified the request. Temporary debug logging on the platform's own preflight request proved the diagnosis, the logging was removed, and the handler was redeployed clean.

After the fix, the platform preflight passed with ~125 ms latency, and practice tasks went 2 for 2: APPROVE on a valid task, REJECT on an expired one, with proof status verified in both cases.

If there is one debugging rule this bug reinforced, it is this: when your own tests pass and the other side fails with an auth error, stop re-checking your credentials and start questioning what both sides think the credential is. Encoding is part of the secret.

Where verification fits in

This is the part of the story that connects to what zkVerify is actually for. A gatekeeper agent is a trust decision: it says "this proof is good, let the payment through" or "this proof is bad, stop it". Without verification, that decision is just the agent's word. With zkVerify, the proof behind the decision can be checked by anyone, without revealing the private details behind it. The agent doesn't have to be trusted — its work can be verified.

That is why the track is scored the way it is, and why a wrong APPROVE costs more than a wrong REJECT. In a world where agents will move money, sign things, and approve things on our behalf, "just trust me" is not good enough. Verification is the difference between an agent you hope is right and an agent you can check.

The honest limitation

Gatekeeper-29k is decision-only. It checks the conditions and the proof metadata, but it does not yet generate Groth16 proofs itself. That has a real cost in the scoring: on provable tasks, a correct decision without a valid proof still scores, but loses 2 points for the missing proof and misses the +0–5 reliability bonus. I am not hiding that — it is the known gap, and closing it (adding real proof generation) is the next piece of work.

What the agent is ready for is Round 4, on Monday 16 November at 18:30 WITA. It is registered, its preflight passes, and its practice record is clean. The rounds it missed (Rounds 1–2) are gone; the remaining rounds are the ones that count now.

What I'd tell someone building their own

Test against the platform, not just against yourself. My handler passed every self-test and still failed the platform's preflight. The two are different test suites.
Treat encoding as part of the contract. A hex string is not the same key as the bytes it decodes to. If a spec doesn't say which one, support both and log which one matched.
When the network won't cooperate, change the architecture, not the goal. Three tunnelling approaches failed; serverless worked in an afternoon.
Score the failure modes, not just the happy path. The trap list — fake keys, replayed proofs, expired conditions — is the real specification. The valid case is the easy one.

Building a verifiable agent turned out to be less about cleverness and more about being precise where it matters: what exactly is being verified, with what key, and what happens when the answer is no.

AgentGames

Gatekeeper-29k is my entry in the Proof Gatekeeper track of Agent Games by zkVerify. The endpoint is live at https://agent-games-gatekeeper-rouge.vercel.app. This article is my Creator Track entry: an honest account of building the agent, including the parts that are still unfinished. Nothing here is a prediction or financial advice — Round 4 hasn't run yet.

DEV Community: Fauzi Darwis

How I Built Gatekeeper-29k: A Verifiable Proof Gatekeeper Agent

How I Built Gatekeeper-29k: A Verifiable Proof Gatekeeper Agent

What a Proof Gatekeeper actually decides

The first problem: my machine couldn't be reached from the internet

The 401 that wasn't an auth failure

Where verification fits in

The honest limitation

What I'd tell someone building their own

AgentGames