Sankalp Gilda
Staff Machine Learning Engineer
Tampa, Florida, United States
Actions
Sankalp Gilda is a Staff ML Engineer and independent researcher focused on epistemic accountability and structured reasoning for AI-assisted workflows in regulated and high-stakes domains. He holds a PhD in Astronomy and has six-plus years of production data science experience spanning time-series analysis, uncertainty quantification, and MLOps -- most recently driving AI for electric-vehicle systems in greentech as well as in oil and gas.
He created tsbootstrap, an open-source Python library for bootstrapped time-series resampling (87+ stars, sktime-integrated), and gave its tutorial at SciPy 2024. His other public OSS spans the security and developer-safety ecosystem -- idna-ip-literal-smuggle-rules, a CodeQL/Semgrep ruleset and gopatch auto-fix codemod for a Go IDNA-canonicalization bug class (UTS-46 digit-fold IP-literal smuggling) he privately disclosed to the Go team in April 2026, and mcp-keyring-injector for session-scoped credential safety in MCP environments. Recent research includes workshop papers at ICLR 2026 -- Logical Reasoning of LLMs (algebraic invariants for LLM reasoning chains and weakest-link reliability propagation) and AI in Finance (epistemic accountability and generator-ratifier disjointness for agentic financial AI). He builds Verity, a reasoning-layer system for AI coding assistants in regulated environments, currently in private development.
Outside work he's drawn to high-commitment activities -- skydiving, scuba diving, kitesurfing -- that reward the same combination of careful preparation and decisive action that good engineering does. He consults across industries through DeepThought Solutions on AI governance, structured reasoning, and ML-for-regulated-domains problems.
Links
Area of Expertise
The Judge Didn't Move The Score. The Parser Did.
A common worry about LLM-as-judge evaluation is that swapping the judge model changes your eval numbers, so the result is really an artifact of which judge you picked. That worry is testable, so I tested it: sixty tasks from the public cais/MASK benchmark, four judge models drawn from different model families, three runs each, seven hundred twenty gradings in total. Within a single judge and across every pair of judges, Cohen's kappa came out to plus 1.000. Zero verdicts flipped. On this benchmark, with this setup, judge choice was not the source of instability people assume it is.
Something else moved nine verdicts, though, and it was not a judge at all. The benchmark's own answer-parser reads the first line in a response that begins with "Answer:," and a response that opens by quoting the question back gets that quote read as the verdict. Switching to a last-match parsing rule moved three GPT-4o gradings and six Gemini gradings, nine verdicts total, purely from an implementation choice that stays invisible in any results table showing only the final score.
The parser sits between the judge and the number you report, unacknowledged, and it turned out to be a third instrument in its own right. If you build or run evals for agents, this talk is the concrete case for treating your parsing code as something that gets audited, not as plumbing underneath the eval. The dataset is public, the models are public, and nothing about the result depends on a product; it reproduces from what's on screen.
Three Jobs, Not One: Why "Sandboxing" Can't Contain Agent Code or Witness What It Did
"Sandboxing" has quietly become one word for three different jobs, and the gap between them is where 2025 and 2026 keep going wrong. Constraining an agent you built is one job. Containing code you didn't build (a tool server off a registry, an extension off a marketplace, another party's sub-agent) is a second, and it's a fifty-year-old confinement problem, not a policy setting. Producing a record of what that code actually did, one an auditor or insurer who trusts neither you nor the code can re-check later; that's the third job. Most tools sold as "sandboxes" do the first job and quietly stand in for the other two.
This talk walks the public incident record (postmark-mcp, Nx "s1ngularity", the Shai-Hulud worms and their remediation-triggered dead-man's-switch, among several others) and groups the incidents by which job failed rather than by protocol or vendor. The pattern is uncomfortable: the protocol is incidental, human review is structurally outmatched (encoding defeats it before execution; the rug-pull defeats it on the time axis), and in nearly every case the after-the-fact story had to be pulled from logs the compromised component itself controlled.
From there I lay out a four-class taxonomy of execution-evidence architectures (proxy-mediator, self-signed history, silicon/TEE, and host-side observation of an isolated substrate) organized by where the observer sits and who holds the signing key, with each class's blind spot named out loud. Then the part most vendors skip: what a signed PASS can honestly claim, why "verified safe" is a phrase to distrust, and the rare-trigger logic bomb that makes it so.
You'll leave with a vocabulary that classifies any sandbox claim in a single question, an entry-by-entry mapping onto the OWASP Top 10 for Agentic Applications, and five questions you can put to any vendor before you adopt their tool.
Your AI Agent Isn't Sandboxed. It's Doing Three Jobs at Once, and Most Tools Only Do One.
If your AI agent framework says it "sandboxes" untrusted code, that one word is doing the work of three different jobs, and most tools only do one of them.
What an agent may attempt is a policy question. Once it's running, containment needs a boundary the code itself has no control over. And knowing what it actually did needs a witness who isn't part of what's being watched. Most agent frameworks do the first job well and quietly assume the other two come free. They don't: the same process that enforces your policy usually shares a trust boundary with the code it is supposed to contain, and a log the sandboxed code helped produce is not independent evidence of what that code did.
I published a paper today surveying nine public 2025-2026 incidents where this exact gap caused a real failure, and sorting every architecture I could find that tries to solve the evidence problem into five classes, split apart by who's actually watching, whether they hold the signing key themselves or only get handed one afterward, and how much of the run they actually get to see. Almost nothing survives an operator free to simply not show you the runs that embarrass them, and that's the uncomfortable part.
This talk is the practical version, in Python terms: how to tell whether a tool you already use is doing one job or three, and the questions to ask before you trust the word "sandboxed," whether it's a vendor's claim or your own side project.
From Vibe-Coded to Audit-Ready: A Reasoning Layer for LLM-Assisted R and Python in Pharma
LLM coding assistants now write a lot of the R and Python that ends up in clinical, CMC, and submission pipelines. This is especially true at smaller biotechs and academic labs that don't have a dedicated validation team. The code usually runs. The reasoning behind it is gone five minutes after the chat closes.
When a QA reviewer or 21 CFR Part 11 inspector asks the obvious follow-up — why this approach, what alternatives were considered, what evidence supports it, when was that evidence last verified — there's nothing to show. The chat is gone, the model is stateless, and you end up hand-waving through the answer.
This talk is about something that closes part of that gap: an MCP server that turns ordinary AI coding sessions into persistent reasoning trails you can actually audit. The assistant gets pushed through a five-step loop. Generate competing hypotheses. Verify them against constraints. Gather evidence — tests, citations, whatever prior decisions apply. Audit for bias and reliability. Then commit a Design Rationale Record. Every record lands in a per-project knowledge graph with cryptographically chained evidence, three-level assurance promotion, and a freshness clock that flags stale claims so they can be refreshed, deprecated, or covered by a formal waiver. It plugs into Claude Code, Cursor, Gemini CLI, and Codex CLI without lock-in.
The demo walks an LLM through drafting an admiral-style ADaM derivation in R. The reasoning layer records why one imputation strategy was chosen over two alternatives. A Python validator then reproduces the analysis. Both get rolled into a Quarto report whose appendix carries the full decision trail. I'll map each captured artifact to specific clauses of 21 CFR Part 11 (audit trail and electronic records), GAMP 5 (Cat 5 custom-code reasoning as validation evidence), FDA's December 2024 PCCP guidance for AI/ML SaMD (modification protocol with valid_until), and EU AI Act Article 14 (human makes the final decision). The point is what the regulator can verify, not just what looks good in a code review.
A few things this is not. It doesn't filter hallucinations. It doesn't replace human review. Nothing here has been validated against a real submission, and there isn't a pharma-specific benchmark yet — building one is harder than it sounds, and I'll spend a few minutes on what it would actually take. If that problem interests you, come find me after.
You'll leave with:
- a working primitive for capturing AI-assisted-code decision trails today
- a concrete crosswalk from AI-coding artifacts to regulator-recognized record requirements
- a reproducible pattern for combining R and Python under one auditable layer
- some idea of where this helps and where it doesn't
Stack: Go MCP server (single binary), SQLite, Python orchestration, R via shell wrapper. The live demo runs offline on a laptop. Repo and slides afterward.
Sandboxing Does Three Jobs. It's Failing At Two Of Them.
"Sandboxing" gets used to mean three different things at once: keeping foreign code from touching what it shouldn't, keeping the system honest about what actually ran, and producing a record a third party can check without trusting the box that made it. Most sandboxing work, including most of what ships today as AI agent security, solves the first job and quietly assumes the other two come free. They do not. A system can contain code perfectly and still have no way to witness its own execution, and a system that logs its own execution has produced attribution rather than verification, because the log is a claim the system made about itself.
This is a seven-minute argument for treating those as three separate engineering problems with three separate failure modes, illustrated with concrete cases where the second and third jobs failed silently while the first job worked exactly as designed. The full argument and evidence live at DOI 10.5281/zenodo.21935891.
Techniques in Time Series Analysis for Machine Learning Enthusiasts
Time series data, while prevalent across numerous domains, presents unique challenges and opportunities in machine learning. This comprehensive session delves into the intricacies of time series analysis, tailored for beginner to intermediate data scientists and machine learning engineers. Our focus extends beyond the traditional scope, incorporating cutting-edge methodologies and tools.
In this enhanced tutorial, you'll gain insights into:
Fundamental Concepts and Applications: Understand the various forms of time series data and their relevance in different learning tasks, including but not limited to forecasting and classification.
State-of-the-Art Algorithms: Explore advanced algorithms tailored for time series classification, regression, and forecasting. Learn how these algorithms outperform conventional methods in handling temporal dependencies and patterns.
Uncertainty Quantification: Discover techniques to quantify and communicate uncertainty in time series forecasts, a critical aspect often overlooked in traditional analyses.
Python Libraries Showcase: Get hands-on experience with popular Python libraries like sktime, statsmodels, and prophet. These tools extend the capabilities of standard libraries like scikit-learn to better suit time series data.
Bootstrapping Methods: Learn how to implement bootstrapping in time series to estimate the accuracy and stability of your predictive models.
Anomaly Detection: Delve into identifying unusual patterns or anomalies in time series data, an essential skill in many fields like finance, healthcare, and network security.
Reduction and Composite Strategies: Master techniques like breaking down complex tasks into simpler ones (e.g., using regression for forecasting) and combining multiple strategies (ensembling, pipelining) for enhanced model performance.
Data Transformations and Feature Extraction: Understand the importance of preprocessing steps like detrending and extracting relevant features to improve model accuracy and efficiency.
Interactive sessions with Jupyter notebooks will facilitate hands-on learning, allowing participants to apply these concepts in real-time. Whether you're looking to deepen your understanding or expand your toolkit in time series analysis, this session offers a wealth of knowledge and practical skills.
Containment Without Proof Is Just Hope
Bring an agent or an MCP server you're already running, yours or a public one. We put it inside a containment boundary, then probe it adversarially: tool-call arguments shaped to pass a schema check while still doing something the schema never anticipated, outputs built to slip past a type-confused validator, and a handful of other concrete failure classes pulled from real, recurring defects in verification code, agent-adjacent and otherwise. Everyone leaves with two things: a containment setup they can point at their own agent afterward, and a small, re-checkable evidence artifact from the session itself, something a third party could look at and verify independently rather than a log the same system wrote about itself.
The format stays hands-on throughout; nothing you bring needs to be production-facing.
A Superscript One Walks Past the Guard: Six Byte-Level Escapes in Reviewed Code
An agent asks its HTTP tool to fetch 0.¹.0.0. That is not an IP address, and the egress allowlist standing in front of the tool agrees, so the request goes through. UTS-46 mapping then folds the superscript one down to a plain 1, and what the socket opens is 0.1.0.0, which the allowlist would have refused on sight.
Nothing technically malfunctioned. The guard and the runtime read the same request and saw different bytes, and in an agent stack that is architecture rather than accident. A guardrail, a policy engine, a tool runtime, a provenance verifier: each sits behind a decode boundary, some distance from whatever finally consumes its input. Agent architectures multiply those boundaries. Check ahead of a transform and you have approved something the transform is about to change. Check after a decode and whatever the decode discarded is already gone. The boundary decides which mistake you get.
I have watched this happen six times now, independently, in reviewed code written by people who knew the rule perfectly well. Myself among them. Twice. One vocabulary-safety check passed a label because what it inspected was a decoded string; the bytes underneath were ill-formed CESU-8, and a lenient decoder had substituted them long before the check ran. Another: five implementations of one specification, handed byte-identical bytes, rejected them unanimously and disagreed about why. Three tested the parse type, so 1e2 fails as a non-integer token. Two tested what the literal denotes, so the integer 100 fails only because 1e2 spells it wrong. All five reject, so no accept-or-reject conformance test can see the disagreement.
Check the bytes the consumer will actually act on, not whatever arrived at your door.
Sankalp Gilda
Staff Machine Learning Engineer
Tampa, Florida, United States
Links
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top