▲About
maria.khan
I'm a backend platform engineer at a fintech. I work across the layers between an application and the kernel, on securing the code that runs there, and on the AI tooling getting built next to it all. I'm equally interested in what ships cleanly and what doesn't.
Open source I've shipped
A context-aware secret scanner I designed and built end to end — the Rust engine, an integration agents call over MCP, an editor extension, and a package in every major ecosystem. Free and open source.
leakferret
Context-aware secret scanner
One Rust binary that finds hardcoded secrets, confirms which ones are actually live by calling the provider, and rewrites them to read from the environment. I designed and built the engine, the signed fixture catalog, the provider verifiers, and the whole release pipeline.
@leakferret/mcp
A secret check the agent runs itself
An MCP server so a coding agent can scan, verify, and rewrite secrets before it ever writes a commit. Published to the official MCP Registry, so any registry-aware editor can discover it.
leakferret for VS Code
Scan on save, fix in place
A VS Code extension that scans on save, classifies findings with the editor's own LLM (no extra API key), and offers a one-click quick-fix that rewrites a literal to an env lookup. Published to both the VS Code Marketplace and Open VSX.
One binary, five ecosystems
A package in every major registry
The same engine shipped as a Ruby gem, an npm package, a Go module, and a GitHub Action — each a thin wrapper that fetches one signed binary, with pinned-checksum plus cosign verification across all of them.
Contribution activity
840 contributions in the last year
Aggregate activity across public and private work.
How I work
I think in systems. My first move on any problem is to figure out which layer it actually lives in, who owns the mutable state, what the failure modes are at production scale, and where the abstraction stops being true. Postmortems, design reviews, performance investigations all follow the same shape.
I use AI heavily, but I do not ship AI-generated code. My workflow goes the other direction. I treat AI as a fast pair-programmer that needs supervision, direction, and a clear plan to be useful. I keep the thinking, the structure, and the verification. AI fills in the parts where typing slows me down.
I am not a translator from prompt to code. I am the person who knows what the right thing is, who decomposes the problem correctly, who notices when the AI is confidently wrong, who refuses to ship the convincing-but-broken answer. That is the work I do, and the work I think will keep mattering.
Areas I've worked across
Reading the source
Reading the source of every library I depend on. Tracing performance bugs from the application framework down through the database driver, into the C client library, into the operating system. The fun part of any investigation is the layer where the abstraction stops being true.
Database internals and operations
MVCC, lock acquisition, advisory locks, connection pooling and the lifecycle that has to match how a proxy behaves under SIGTERM, large-table migrations that ship without errors or downtime. The operational edge of a database, not the SQL on top of it.
Distributed coordination and shared state
Cross-component coordination so shared state stays consistent without a redeploy and without a half-mutated window. Watchers, channels, snapshots, and patterns borrowed from outside the language ecosystem that solve the same problem differently.
Observability tooling
Log routing, telemetry sampling, and tracing context that engineers can flip live during an investigation. An observability layer is supposed to bend with the question being asked; most ossify the moment they ship.
Observability beyond application logs
Reaching for low-level tracing and profiling when the application logs don't have the answer. The slow query that turns out to be a microsecond lock wait. The OOM that's actually a slow memory allocation during GC. Where the next layer of platform observability lives.
Load testing as a discipline
Designing benchmarks that match the production shape, not just the synthetic happy path. A bench that mirrors real traffic teaches you something the synthetic one never will.
Incident triage
The first fifteen minutes of an incident, where the routing decisions get made and most of the recoverability lives.
Secure code and vulnerabilities
Writing code that doesn't ship the obvious vulnerability classes. Finding the ones that did. Threat-modeling the codepaths nobody re-reads, hunting for the patterns nobody questions, designing secrets-handling systems that survive a rotation, surfacing the failure modes before a pentest does. Something I wish I had more time to do.
AI / LLM infrastructure
Retrieval pipelines, agent runtimes, evaluation harnesses, context routing. Most of the engineering in LLM products lives in the infrastructure around them, not in the model itself.
Currently digging into
Internals of the daily stack
Reading the internals of the production tools I actually use: Redis's data structures and persistence model, Kubernetes's control loop and scheduler, RDS's storage and failover machinery. Knowing the source means I trust the behavior at 2am.
Async delivery patterns
How different ecosystems handle scheduled work, delayed delivery, retry budgets, and idempotency under failure. The shape of the problem stays the same; the patterns each language community settled on are where the interesting questions live.
Concurrency across runtimes
Reading how different runtimes approach concurrency: green threads, fibers, actors, structured concurrency, work-stealing schedulers. Same primitives, very different design choices, all worth borrowing from.
Stacks I've shipped or studied
Daily Hands-on Watching
Nothing in that category yet.
Featured writing
-
Catching the secret before the commit, not after the audit
The cheapest place to catch a hardcoded secret is before it is ever committed. On false-positive fatigue and why scanners get muted, the gap between looks-like-a-key and is-this-key-live, and how I built leakferret to classify, verify, and rewrite secrets in the editor, the pre-commit hook, and the AI agent itself.
-
What concurrent Ruby looks like, twelve years after the book
Walking the foundations of Storimer's Working with Ruby Threads with the actual race conditions and deadlocks you'll see in production, then walking the primitives that have shown up since 2014: Ractors, Fiber.scheduler, async, Falcon, and the snapshot-plus-AtomicReference pattern I keep using for hot-path lookups.
-
Debugging Redis::CannotConnectError in Ruby
A month of thousands of connect-timeout errors a day from a Rails app on redis-rb. The dead ends (pool size, KEDA, DNS, kernel knobs you can't tune on managed Redis), the error taxonomy that actually narrows it down, and the four-line fix that turned out to be a footgun in your own code.
Achievements
- 2024 Grace Hopper Celebration India — Scholarship Award (AnitaB.org)
- 2023 Amazon ML Summer School recipient
- 2023 CodeElevate scholarship recipient
- 2022 Mercor AI Chatbot Hiring Challenge 2.0 — 4th globally
- 2022–24 TalentSprint × Google Women Engineers Program (2-year cohort)
Education & certifications
- 2021–25 Bachelor of Technology in Computer Science & Engineering. CGPA 8.5/10 (3.7 GPA on the 4.0 scale)
- cert INE Certified Cloud Associate — INE
- cert Cyber Security Bootcamp for Women — ICTTF — Cyber Risk Academy
Open to
$ ./hire.sh
> open_to: backend platform, infrastructure, dev tools,
observability, low-level systems, security
> exploring: kernel observability, security craft,
anything between the app and the OS
> shape: full-time or contract
> location: remote / hybrid (India)
> contact: [email protected]
> exit 0 - →Building developer tools: debuggers, profilers, tracers, observability that sees one layer down from where engineers usually look.
- →Low-level systems products: anything that touches syscalls, the kernel, ELF, language runtimes, or the layer between application code and the OS.
- →Platform and infra teams where contention actually shows up at production scale.
- →Observability or reliability tooling, especially the AI-native side of it.
- →AI infrastructure work: agent runtimes, retrieval, evaluation, context routing.
- →Internal-tools or developer-platform groups where the same engineers shape both the API and the operational story.
Ask me about
Bring me something you're working on. Pick whichever shape fits and the email opens with a subject already in it.