DEV Community: Abidit Shrestha

Building phi-guard-mcp: Catching PHI Leaks in AI-Generated Code

Abidit Shrestha — Sun, 30 Aug 2026 16:15:28 +0000

The Problem Nobody's Watching

Your AI coding agent just shipped a patient's diagnosis to OpenAI.

The code worked. The tests passed. The PR got approved.

Nobody noticed — because nothing was watching for it.

This is a new class of mistake. Infrastructure scanners like Prowler check S3 bucket encryption, not whether your code interpolates patient.name into a prompt. The FHIR MCPs help agents read clinical data — they don't check whether other code is leaking PHI into logs or analytics.

The code is doing exactly what it was written to do. That's the problem.

What PHI Guard MCP Does

phi-guard-mcp is a local-first MCP server that catches PHI (protected health information) before it hits LLM calls, logs, or analytics events.

It runs entirely on your machine over stdio. No network calls. No telemetry. No data ever leaves your environment.

Two tools:

scan_code — Walks your repo and flags lines where a sensitive identifier (patient, diagnosis, mrn, ssn, dob) appears on the same line as a risky sink (openai, anthropic, console.log, logger, .track())
redact_suggest — Takes any raw text and returns a redacted version with PHI replaced by placeholders

Example:

{
  "text": "Patient John Doe (MRN-12345), DOB: 01/01/1980"
}

{
  "redacted": "Patient [NAME] ([MRN]), [DOB]",
  "detected": [
    {"type": "mrn", "value": "MRN-12345", "confidence": 0.9},
    {"type": "dob", "value": "01/01/1980", "confidence": 0.85},
    {"type": "name", "value": "John Doe", "confidence": 0.8}
  ]
}

What It Catches

PHI Type Confidence Example Matches
SSN 0.95 123-45-6789
MRN 0.90 MRN-12345, MRN: 12345
DOB 0.85 01/01/1980, born 3/14/75
Name 0.80 Patient John Doe
Phone 0.75 555-867-5309
Email 0.70 jane.roe@example.com
The patterns are deliberately narrow. A false positive that trains someone to ignore the tool is worse than a missed match.

Tested Against Real Leak Patterns
6/6 planted leaks detected across 5 different sinks (OpenAI, Anthropic, Sentry, Winston, PostHog/analytics)

0 false positives across 5 clean-code fixtures

Scans .ts, .js, .tsx, .jsx, .py, .go

Skips node_modules, dist, build, .next, .turbo, and dotfiles

What This Is Not

Not a HIPAA certification or legal compliance guarantee — it's a linter-grade signal, not an audit

Not a competitor to Prowler or AWS Config — those scan infrastructure, this reads source code

Not a hosted service — it runs entirely on your machine, no BAA required

How to Use It

Installation:

npm install -g phi-guard-mcp
With Claude Code: Add .mcp.json to your project root:

{
  "mcpServers": {
    "phi-guard": {
      "command": "node",
      "args": ["/absolute/path/to/phi-guard-mcp/dist/index.js"]
    }
  }
}

Command Line:

phi-guard-mcp
Then ask your AI agent:

"Scan this repo for PHI leaks in prompts and logs"

or

"Redact this text: 'Patient John Doe (MRN-12345) was admitted on 1980-01-01'"

Why I Built This

This came from watching AI agents write code that ships patient data into prompts, logs, and analytics — with total confidence, because nothing was watching for it.

The gap I saw was real: no existing tool catches this. The code works. Tests pass. PRs get approved. But patient.diagnosis just went to OpenAI.

So I built the thing I wished existed.

Links

GitHub: github.com/Abidit/phi-guard-mcp

npm: npmjs.com/package/phi-guard-mcp

MCP Registry: mcpservers.org/servers/abidit/phi-guard-mcp

MIT licensed. Open source. Free to use, forever.

Feedback welcome, especially if you're building in healthtech or working on AI safety.

The bug I "fixed" that taught me more from being closed than merged

Abidit Shrestha — Fri, 28 Aug 2026 01:25:18 +0000

A few weeks ago I opened a PR on a large open-source design system to fix a contrast issue I'd spotted in dark mode — a text/background color pairing that failed WCAG AA. I patched it, added regression tests, and got an initial approval. Then the maintainer reversed course, and eventually the PR was closed outright. Here's what happened, and why I think it was the right call.

The bug

The component in question used light-dark() set inline to switch colors between light and dark mode. In dark mode, the contrast ratio between the text and background token pairing was below the 4.5:1 threshold for WCAG AA. My fix bumped it into a 4.37–10.57:1 range depending on state — a clear improvement, and it got an initial approval.

Where it went sideways

Before merging, the reviewer went back and actually traced the token pairing across the rest of the system — and found the same underlying tokens failed contrast in several light-mode themes too, not just dark mode. A second component using the identical token pairing had the same latent bug.

The problem: my fix lived inside one component (Avatar.tsx). A light-dark() call set at the component level can only ever resolve one branch per color scheme. It fixed the specific failure I'd noticed, but it structurally couldn't reach the other failures, because they lived in other components consuming the same broken token pair. Patching one consumer left every other consumer of that token exactly as broken as before.

The actual fix — and why it wasn't mine to make

The reviewer's conclusion was that this needed to be fixed at the design token definition itself, not in any individual component. That's the only place a fix propagates to every consumer and every theme at once, instead of playing whack-a-mole component by component.

A few days later, the PR was formally closed with a note that color-token and palette changes are now being coordinated as owner-led accessibility work, rather than through parallel, uncoordinated implementation PRs from individual contributors — and pointed toward a tracking issue for the broader initiative.

They also linked a separate, already-merged PR that added a lint rule forbidding light-dark() in component source going forward — codifying the exact anti-pattern my PR had (accidentally) demonstrated.

What I took away from this

A locally correct fix can still be the wrong fix. My patch genuinely improved contrast for the case I tested. It was still wrong, because it solved the instance instead of the root cause, and would have left the system with two different fixes to the same underlying problem living in two different places.
Look for the shape of the bug, not just the instance. The real signal was asking "does anything else in this codebase depend on the same token pairing?" — which is a question about the system, not the component. That question is what turned a one-line fix into a systemic finding.
Getting your PR closed isn't the same as being wrong. The maintainer was explicit that the finding was correct and valuable — the fix itself was closed on architectural grounds, not because it was broken. Open source review, done well, is about protecting the health of the whole system even when it costs an individual contribution its merge.
A closed PR can still be a good outcome. The findings led to a lint rule preventing the anti-pattern going forward, and to color-token ownership being reorganized into a single coordinated effort instead of scattered fixes. That's a better long-term result than my one component getting a green checkmark.

If you're contributing to a large open-source codebase for the first time: it's worth getting comfortable with the idea that "correct and closed" is a completely normal outcome, and often a sign the review process is doing exactly what it's supposed to.

I built the first eSewa and Khalti MCP servers — here's how

Abidit Shrestha — Sun, 05 Apr 2026 15:13:21 +0000

The Model Context Protocol (MCP) lets Claude AI interact with external tools and APIs. I just shipped the first MCP servers for Nepal's two biggest payment gateways: eSewa and Khalti.

Why this matters

Nepal's digital payment landscape is booming. eSewa has over 8 million users and dominates the market, while Khalti is the second-largest payment gateway. But until now, there was no way for Claude to interact with these systems programmatically. If you're building an AI-powered app that needs to process payments in Nepal, you were stuck writing custom integrations.

What these servers do

esewa-mcp exposes three tools:

esewa_initiate_payment – Start a transaction
esewa_verify_payment – Confirm a payment succeeded
esewa_get_transaction_status – Check payment status anytime

khalti-mcp exposes three tools:

khalti_initiate_payment – Create a payment request
khalti_lookup_payment – Retrieve payment details
khalti_verify_payment – Verify transaction completion

Both work directly with the official APIs and sandbox environments for safe testing.

The interesting technical challenge: eSewa's HMAC signature

Here's where it got tricky. eSewa uses HMAC-SHA256 signatures to authorize requests, but the fields must be signed in exact order: total_amount,transaction_uuid,product_code. Sign them out of order and the payment fails silently. This tight coupling between field order and cryptography meant I had to be surgical about how the signature is computed. Any deviation — even a typo in field names — breaks the whole flow.

Getting started

Install either server with a single command:

npx -y esewa-mcp
npx -y khalti-mcp

Then add to Claude Desktop config:

{
  "mcpServers": {
    "khalti": {
      "command": "npx",
      "args": ["-y", "khalti-mcp"],
      "env": {
        "KHALTI_SECRET_KEY": "your_secret_key",
        "KHALTI_ENVIRONMENT": "sandbox"
      }
    },
    "esewa": {
      "command": "npx",
      "args": ["-y", "esewa-mcp"],
      "env": {
        "ESEWA_MERCHANT_CODE": "EPAYTEST",
        "ESEWA_PRODUCT_CODE": "EPAYTEST",
        "ESEWA_SECRET_KEY": "your_secret_key",
        "ESEWA_ENVIRONMENT": "sandbox"
      }
    }
  }
}

Then just ask Claude naturally:

"Initiate a Khalti payment for NPR 500, order ID invoice-001"

"Verify eSewa transaction UUID abc-123"

A testing tip

Both eSewa and Khalti provide sandbox environments with free test credentials — no real money involved. I built these servers to use sandbox by default so you can develop safely.

What's next

These are production-ready v1.0.1. If you're building AI-powered commerce for Nepal, check the repo and open an issue.

npm: khalti-mcp · esewa-mcp

GitHub: https://github.com/Abidit/eSewa-Khalti-mcp

I'm a Senior Software Engineer. I Had No Business Writing Courses. I Did It Anyway.

Abidit Shrestha — Wed, 25 Mar 2026 09:04:23 +0000

Let me be upfront about something: I am not a teacher.

I'm a senior software engineer. I write code for a living. I've shipped production systems, reviewed thousands of pull requests, and debugged things that had no right being as broken as they were. But explaining concepts to beginners, structuring a curriculum, deciding what order to teach things in — that is a completely different skill, and I had almost none of it when I started.

I now have six published courses on Programiz, including a full JavaScript game development skill track. Here's the honest story of how that happened.

The opportunity I almost didn't take

When Programiz approached me about building a JavaScript skill track, my first instinct was to say it wasn't really my thing. I'd written some small articles and blog posts over the years, but a full course? Multiple courses? That felt like someone else's job.

I took it anyway.

Not because I was confident. Because I was curious whether I could do something I'd never done before — and because I had tools available that didn't exist a few years ago.

How I actually built it

I want to be honest about this part because I think a lot of people gloss over it: I used Cursor and Claude heavily throughout this process. Not to replace my thinking, but to do things I couldn't do efficiently on my own.

Here's what that actually looked like:

Structuring the curriculum — I'd describe what I wanted students to be able to do at the end, and use Claude to stress-test the sequencing. Does this concept need to come before that one? Is there a gap here? Having something to push back against is faster than staring at a blank page.

Building the reference code — The Brick Breaker capstone project has a Ball class, a Paddle class, a Brick class, a Game class. Getting that code to a point where it was genuinely teachable — clean variable names, strict separation between update() and draw(), no shortcuts that would confuse a beginner — took iteration. Cursor was open the entire time.

Drafting explanations — Writing for beginners is harder than writing for peers. I'd draft an explanation, and use Claude to tell me where it assumed too much prior knowledge. Then I'd rewrite it.

Reviewing my own work — This one surprised me the most. Having an outside read on a draft — even an AI one — catches things you stop seeing after the fifth revision.

None of this felt like cheating. It felt like having a very patient, very fast collaborator who never got tired of my questions.

showing the launch method with angle calculation" width="770" height="490">

Where I almost stopped

About three weeks into the first course, I hit a wall.

I was trying to write a comprehensive ES6 fundamentals module — arrow functions, destructuring, modules, iterators, the works. I wanted it to be complete. I wanted to cover everything. The review process destroyed me. Every pass surfaced new gaps, new things I hadn't explained well enough, new topics that felt incomplete without adding three more topics.

I almost quit at that point. Not because the material was too hard, but because I was approaching it wrong.

The shift that saved the project: I stopped trying to be complete and started asking a different question. Which of these concepts actually shows up in the game we're building? If a concept didn't have a clear home in the Brick Breaker capstone, it didn't belong in the course. That constraint made every decision easier and every chapter tighter.

The lesson I'd pass on to anyone trying something similar: plan in chunks, not in coverage. Pick a concept, find two or three real places it gets used, teach it through those. Don't try to give a complete picture on the first pass. Completeness is the enemy of clarity.

What the track looks like now

Build Games with Vanilla JS is live on Programiz as Skill Track 2. Six courses:

Game Logic with JavaScript — variables, conditionals, functions, scope through a game-thinking lens
Whack A Mole — a DOM and events mini-project early, so students get a win before the harder content
Modern JavaScript Essentials — ES6 features placed after the first mini-project, not before, so students have context for why they matter
Canvas Foundations — the <canvas> API: drawing, animation loops, input, collision detection
Brick Breaker with JavaScript — the capstone where every concept from the track lands in one real project
Rapid Build with Claude Code — a standalone weekend course on building and deploying an app with AI tools

The sequencing isn't accidental. Whack A Mole sits before the ES6 module because abstract syntax makes more sense after you've already built something. Canvas Foundations only teaches what shows up in Brick Breaker. Every decision was made by working backward from the capstone.

What I know now that I didn't know then

Writing a course as a senior engineer is humbling in a specific way. The technical part is fine — I know JavaScript well. The hard part is that knowing something deeply and being able to teach it are not the same skill at all.

Teaching forced me to find the edges of my own understanding. If I couldn't explain why the ball position needs to be corrected before the velocity reverses — not just that it does — I didn't actually understand it as well as I thought.

I also learned that AI tools don't lower the bar for this kind of work. They raise what's possible for one person working alone. The courses exist in the form they do because I could iterate faster, get feedback faster, and catch mistakes faster than I could have otherwise. The judgment calls — what to include, what to cut, how to sequence — were still mine.

Why I'm writing this

I'm not writing this to tell you AI makes everything easy. It doesn't.

I'm writing this because I'm a senior engineer who grabbed an opportunity outside his comfort zone, used every tool available, got humbled by it, figured it out, and shipped something real. If that's the kind of person you want to follow — someone who moves toward hard things and works out how to do them — then stick around.

There's more coming.

Abidit Shrestha is a senior software engineer and course author at Programiz, where he builds JavaScript learning tracks. Follow him on Dev.to and Medium for more.

Discovery: The Hidden Bug Killing Learning Platforms

Abidit Shrestha — Mon, 29 Dec 2025 14:12:01 +0000

For a long time, we believed learners struggled because problems were hard.

Turns out, many never even reached the problem.

While working on Guided Projects at Programiz PRO, we started sitting in clarity sessions and talking directly to users. Not surveys. Not analytics. Real conversations.

One pattern kept repeating:

users weren’t stuck — they were lost.

They didn’t ask for new features.

They asked things like:

“Where do I start?”
“What should I do next?”
“Is this part of the course?”

That’s when it became clear:

learning friction often starts before learning begins.

Features don’t matter if they’re invisible

We had content.

We had projects.

We had structure.

But poor discovery made them irrelevant.

No amount of complexity or polish can fix that.

From assumptions to conversations

Instead of guessing, we shifted focus:

User interviews
Clarity sessions
Observing hesitation, not just clicks

The insights were uncomfortable — and incredibly valuable.

What we changed

Our focus moved from “adding more” to:

Clearer entry points
Stronger learning flow
Reducing cognitive load early

Because when users know where to begin, they’re far more likely to finish.

The bigger lesson

Learning platforms don’t fail because content is weak.

They fail because the path isn’t obvious.

And the only way to see that?

Talk to users. Watch them struggle. Listen carefully.

That shift has changed how we build — and how we think about learning.

Turning Complex Algorithms into Interactive Visual Stories: My Journey

Abidit Shrestha — Wed, 27 Aug 2025 14:58:08 +0000

When I started working on algorithm visualizers at Programiz, I didn’t think much about making them interactive. But after tackling a few problems, I realized: algorithms are stories, and everyone learns better when they can see the story unfold.

🎬 Act I: The Stack That Stunned a Professor

The easy part was coding a rough version. The hard part? Polishing it until anyone could follow the story just by watching.

When we finally showed it to a university professor (a Programiz customer), his reaction was priceless.

“This makes debugging and teaching so much easier. You can pause, play, and see exactly what’s happening in every step.”

That’s when it hit me: visualization isn’t about code. It’s about clarity.

🎬 Act II: The Queue That Fooled My Brain

Queues are simple, right? FIFO. Done. No visualizer needed.

Wrong.

I made queue elements slide from right to left (like an array on wheels). Suddenly, everyone got it without me saying a word.

The tricky bit was dequeue. Animations don’t like disappearing acts. It was Stack Pop all over again. After some wrestling with it, I got the motion flowing.

When I demoed it, the professor pointed out something fascinating:

“This left-to-right flow actually matches how our brain tracks objects naturally.”

Turns out, even human cognition agreed with FIFO. 🧠

🎬 Act III: Knapsack — My First Big Heist

The infamous 0/1 Knapsack Problem. Students fear it. Developers avoid it.

I built a Knapsack Visualizer that doesn’t just solve it but lets you:

Step through decision-making at each subproblem
Watch dynamic programming build the table live
Actually see optimal substructure and overlapping subproblems in action

This project taught me: building is easy, polishing is hard.

Animations, UI, logic, storytelling — I had to touch every piece.

But the final result? A tool I wish I had when I first learned DP.

🎬 Act IV: Coin Change in 3 Days

And then came my fastest build: the Coin Change Visualizer.

From scratch to production in just 3 working days.

This wasn’t speed for speed’s sake. It was proof that with the right process, clarity, and focus, even complex algorithms can be made intuitive.

Tested on all ages — from students to professors — it clicked instantly. No blank stares. No groans. Just “aha” moments.

🌍 Why This Matters

Algorithms don’t have to be intimidating walls of logic.

With the right design and engineering, they become stories people can watch, follow, and remember.

That’s what we’re building at Programiz: tools that lower barriers, make learning intuitive, and give anyone the confidence to say, “I understand this.”

For me personally, this journey wasn’t just engineering — it was proof of what happens when creativity and execution meet.

🚀 Closing Thoughts

If you’ve known me, maybe you didn’t expect me to go this deep into building algorithmic visualizers. Surprise 😉

If you didn’t know me before, now you do:

I build things that turn complexity into clarity.

I make algorithms human.

And I’m just getting started.

🔗 Try one of the visualizers here: KnapSack Visualizer

💬 I’d love to hear your thoughts:

What algorithm should I tackle next?
What’s the one concept you wish had a visualizer when you first learned it?

DataStructures #DynamicProgramming #Visualization #SoftwareEngineering #EdTech #Programiz #OpenToWork #NepalDevelopers