Sushant Poudel

I find where an autonomous agent's tool boundaries leak, then close them.

sushant.poudel2028@gmail.com · Bhaktapur, Nepal (remote, worldwide)
github.com/sushant-me · linkedin.com/in/sushant-poudel2028 · sushantpoudel2028.com.np

Agent & LLM security Memory-safety in C/C++ Evaluation design Edge / offline inference

Email me Check my claims

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.
• And it keeps running after I leave: the audit ships as a composite GitHub Action — uses: sushant-me/mcpaudit@v1 with the lock file committed — so a declaration that changes after approval fails the build instead of being noticed later. The agent review has the equivalent in uses: sushant-me/agentbound@v1.
• 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.
• The same three checks in Rust, with a green badge: toolgate is a single static binary — confusable names, hidden Unicode in a description, and destructive tools with no readOnlyHint. Its CI asserts what a checker usually gets wrong: that it exits non-zero on input it cannot parse, and that all three checks still fire on a server built to trip them. A checker that reports "clean" when it could not read its input is worse than no checker at all.
• 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 Bhaktapur — 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

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.

sushant.poudel2028@gmail.com