Every claim on this page is checkable, and checked weekly. sushant-me/reputation lists each claim I make,
names the public source it came from, and re-runs those checks in CI once a week — it turns red the
moment one stops holding. Claims that cannot be checked from outside are marked
on request rather than mixed in with the verified ones.
git clone https://github.com/sushant-me/reputation && cd reputation && python3 verify_evidence.py
What I can do for you
1 · Agent and LLM security review
Your agent executes actions — calls tools, touches files, moves money, runs commands — and
role-based access control authenticates the identity without having any opinion about whether a
given action should happen. I review the stack for the failure modes that actually occur:
prompt injection through retrieved content, tools that shadow framework built-ins, confirmation
gates that fail open, and destructive actions reachable without an independent check.
What you get: a written finding list, each item with a minimal reproduction, the mechanism at file and line, and a suggested fix.
See it before you buy it:a sample review — a deliberately vulnerable agent I wrote, and the four findings I would return for it, runnable with one command. The same structure is what you receive.
And the implementation:policygate — a fail-closed gate for agent tool calls that I wrote because of a number: my paper measured a locally served 3.8B model approving 23.5% of the proposals the policy would have blocked. So in the library a model can deny or escalate and cannot authorise; a failing evaluator falls through to a refusal; and every decision lands in a tamper-evident audit log. It ships adapters that wrap an MCP server, a LangChain-style tool or a provider function call — duck-typed, so gating a call adds no dependency — and a server whose tool names collide with the framework's own is refused before any call happens.
Typical shape: 3–5 days for one agent product; fixed scope agreed in writing before I start.
Background: MCP tool-shadowing fixes open against three of Google's agent frameworks; a paper on local policy verification for agents; the agentbound detector for this bug class.
2 · MCP server audit — before you connect to it
A tool description is not documentation: it is injected into the model's context, so it
can carry instructions. I review the declarations your client receives from a server's
tools/list — and pin them, so a description that changes after you approve
it is reported instead of silently steering the agent.
What you get: a written audit — reserved-name collisions (a server tool that
silently displaces a framework primitive), instruction-shaped text, invisible Unicode
with any hidden payload decoded, look-alike names, destructive tools declaring
readOnlyHint, and unconstrained sink parameters — plus a lock file that
turns the next change into a diff.
Audit becomes enforcement: the audit emits the starting policy for policygate — collisions and instruction-carrying descriptions deny, ambiguous tools escalate, clean read-only tools are allowed, and anything the audit never saw escalates because the gate refuses by default. You get a policy you can read, a diff when the server changes, and a gate that enforces it per call.
See the deliverable first:mcp-audit-sample is a deliberately risky vendor server and the audit I would return for it — a critical name collision, an instruction hidden in the Unicode tag block, a description that tells the model to add credentials to its summary, a destructive tool declaring readOnlyHint, and a look-alike name pair. Ten findings, two clean tools, the generated policy, and a demo.py that exits non-zero if a finding stops reproducing. Synthetic target, clearly labelled — not a client engagement.
Nothing leaves your machine. The audit is a local static check — no network, no credentials, no SDK, and your server's declarations are never uploaded anywhere. Worth knowing when you compare: the best-known scanner in this space inspects declarations locally and then sends them to a hosted endpoint for analysis, which is a legitimate design and a different trade. You should know which one you are buying.
The tool is public:mcpaudit
— run it yourself first, and hire me when you want the review and the lock file
maintained.
Typical shape: 1–2 days for a small server estate; fixed price.
Detector benchmarking: the same corpus work is available for your own scanner —
a labelled corpus of agent
tool-boundary cases and a harness that scores precision and recall against it, so "our scanner
catches these bugs" becomes a number. It covers tool declarations, framework source, and
declaration drift — a tool description edited after you approved it, which takes two
states of the same server to see and is the shape a rug pull has. My own two detectors are
measured in public there, all three rows at 1.000 precision and recall — and the second
number is only 1.000 because the corpus found a real false positive in it, which I then
fixed and re-measured.
3 · Memory-safety and fuzz-harness work (C/C++)
Memory bugs in the libraries everything else is built on, plus the harnesses meant to catch them.
I filed five memory-safety issues against Google's s2geometry — a NULL dereference on
the documented traversal path, an out-of-bounds read, a 16 GiB allocation from a 117-byte input, and
a 2.4 GiB allocation reachable from a 28-byte input — each with a standalone reproducer.
In libphonenumber I found an OSS-Fuzz harness that was asserting 0.00% line
coverage of the code it targeted; the corrected one reaches 93%.
What you get: fuzzing set up or repaired, crashes triaged under ASan/UBSan with reproducible evidence, and a clear statement of what is and is not reachable from untrusted input.
Typical shape: 2–5 days to get a target under a working harness and produce the first triaged findings.
4 · Evaluation design for AI features
"It works" is not a measurement. I design evaluations with controls that can fail: a shuffled-label
floor, an ablation that must collapse, a deliberately broken system that must be caught. My current
paper ran 600 policy scenarios per condition on a 3.8B model inside a 4.2 GiB budget, and the
headline is the result that contradicted my hypothesis — JSON-constrained output without a
reasoning field was the least safe configuration of the three, at 46.2% unsafe accepts
against 17.2% unconstrained.
What you get: an evaluation you can re-run, with the failure taxonomy, the controls, and an honest statement of what the numbers do not cover.
Also useful for: model and vendor evaluation, red-team exercises, and "is this feature safe to ship?" decisions.
How I work
Written scope first. Deliverable, date, price, and what is explicitly out of scope — before any work starts.
Paid trial available. A small scoped task, paid, so you can judge the work rather than my profile.
50% upfront for a first engagement.
Rates: hourly and fixed-scope; rate card on request. Remote from Kathmandu — I invoice through Payoneer or Wise, so there is no invoicing problem for a US or EU client.
I report the negatives. If my own fix turns out to be wrong, you will see the trace that shows it — the writeup The crash that wasn't is a pull request I closed on myself for exactly that reason. The same standard applies to my own tools: A benchmark found a bug in my own detector is the false positive my test corpus found in my released scanner, and the three further defects that fixing it exposed.
The receipts
what
check it
Security patch authored, merged, then generalised into google/go-github — my #4556 refused a release-asset upload whose URL pointed off-host; the maintainer replaced it the next day with the broader #4564, "credentials are sent only to configured origins", which is what master implements today and which carries the commit "Address feedback from sushant-me"
A benchmark I wrote found a false positive in my own released scanner — 23 labelled agent tool-boundary cases, precision 0.750 → 1.000, with the failing case named in CI instead of deleted
Two years as an AI engineer at Atmos SoftTech — production ML, full-stack delivery, offline-first agent pipelines
signed experience letter on request
Availability
Open to contract and freelance engagements now, and to full-time AI security / agent
safety roles from graduation. Final-year Computer Engineering at Nepal Engineering
College, so I keep one client engagement at a time alongside it.