skip to content
Mohamed Azahrioui
Mohamed Azahrioui

Mohamed Azahrioui

backend developer, the hague

I build backends, and guardrails for AI agents.

I’m a backend developer in The Hague, two years into a CS degree at Leiden and already writing production code for real clients. What I care about is correctness: code that stops when something is wrong instead of guessing, and that keeps a record you can check.

shipped · in productionthe hague, nl
fetchgate
v0.2.0 on PyPI · 45 tests, no network, no model · verify
reachgate
~14k lines · 422 tests · signed OpenVEX / SARIF receipts
trustgate
runtime authorization on Google Cloud · Vertex / BigQuery
production
CodeHive · Kojac · freelance clients · at 20
available
summer 2027 internship · penultimate-year, BSc expected 2028

guardrails

Three times now I’ve built roughly the same thing. Each one sits in front of a spot where an AI system would otherwise guess, and puts a fixed rule in charge: the rules decide, the model just explains the decision, and you get output you can check instead of trust. I didn’t plan to specialise in this. It just kept being the problem in front of me.

RETRIEVED / FAILED / UNKNOWN

This is the one I put on PyPI. It sits where an agent fetches a web page and checks whether the page was actually read, or whether the request just came back with a 200. A 200 only means bytes arrived, not that you got the page. If it can't confirm a real read, it stops the agent instead of letting it answer anyway. No model, no API keys. One test in the suite deliberately tries to slip a fake read past it, and fails.

read the case →

REACHABLE / UNKNOWN / NOT-AFFECTED

A scanner tells you a vulnerable function exists somewhere in your dependencies. It doesn't tell you whether your own code can ever reach it. On the codebases I tried, roughly four in five “critical” findings couldn't be reached at all. ReachGate walks the code graph to check whether a path exists. If it runs out of budget before it can be sure, it returns UNKNOWN rather than marking something safe it never proved. Every result exports as signed proof you can re-run offline.

read the case →

ALLOW / APPROVAL_REQUIRED / BLOCK

Before an agent does something costly, like issuing a refund, TrustGate looks at the data behind the decision: is it fresh, does it still match the contract it was written against, is the source even connected? An agent can be allowed to act and still be acting on bad data. It returns allow, needs-approval, or block, with the evidence attached.

read the case →

other things I’ve built

writing

all posts →

now

I’m looking for a summer 2027 internship, and I take on backend, RAG, and API work in the meantime. If you have a problem in that area, email me and I’ll tell you honestly whether I can help.

certified · HackerRank Software Engineer verify · HackerRank REST API (Intermediate) verify