We’re sitting down with Dmitrii Volkov, a research lead at Palisade, a California-based AI security lab. His background spans AI, formal methods, and cybersecurity. Known for pioneering alternatives to Tor, contributing to frontier AI risk evaluations, and applying NLP for community health metrics, his work has been featured in policymaker briefings around the world. Join us as we delve into his technical achievements, philosophies, and the challenges he’s faced at the forefront of technology and security.
While leading AI risk evaluations at Palisade, how do you ensure collaboration between researchers, policymakers, and institutions like RAND?
Let me give you a concrete example of how we bridge the gap between technical AI research and policy. Last summer, our BadLlama project showed that you could strip safety guardrails from large language models for less than $200-we’ve since improved that to $10. This was not an academic exercise; it culminated in that surreal moment when Tristan Harris used our findings to confront Mark Zuckerberg directly during a Senate forum. Suddenly, lawmakers who had been skeptical about AI risks were paying attention.
We have found that such demonstrations are much more powerful than any abstract warnings. After we sat down with the legislative director of a California state senator and showed him what an unrestrained AI model could do, he had an immediate visceral reaction to what was no longer a hypothetical. This meeting inspired downstream legislative work. However, we are very careful in how we share our research. While we published our findings about BadLlama, we deliberately withheld the weights, code, and training methodology. This reflects our broader approach: be transparent enough to inform policy while being responsible about not releasing dangerous capabilities. We’ve found this balanced approach helps us maintain credibility with both technical and policy communities.
What is most interesting, however, is how different stakeholders take and use the same research. After our BadLlama paper, for example, the head of AI safety at Meta reached out to ask for our training data so they could see whether Llama 3 was resistant to these attacks. Meanwhile, the UK AI Safety Institute used our findings to inform their summit preparations. It’s about creating research that resonates across these different spheres while advancing the conversation about AI safety in concrete ways.
Your work to provide alternatives to Tor for Iranian users met critical challenges in digital privacy. What do you consider some of the more important technical and ethical considerations involved, and how did you deal with them?
The core challenge in Iran wasn’t about bypassing the censorship-it was about what happens when a country completely cuts the cable to the outside Internet. This set up two really pressing technical challenges and one really critical ethical one.
First, of course, was the purely technical challenge-designing a system that would work even when international connections were cut. We solved this by building a peer-to-peer content delivery network that could function completely on local networks: once a piece of content made it inside the country, it could spread between users without needing any outside connection.
The second was a very specific technical challenge: making this work on regular, resource-constrained mobile phones. Iranian mobile phones often had spotty connections and underpowered CPUs. We carefully optimized our networking stack to be extremely robust to intermittent connectivity, using as little CPU and memory as possible.
But the ethical challenge was the most critical: in some regimes, merely being caught using circumvention tools can lead to arrest. This meant every design decision had to be evaluated not just for technical effectiveness, but for how it might affect user safety. We spent considerable time ensuring that CENO’s network traffic would blend in with normal browsing patterns and that users could plausibly explain the app’s presence on their device.
What made this project satisfying was seeing the metrics that showed it was genuinely helping-reach over 28,000 users and 2M pages cached in places like Iran where digital access was most constrained. But more importantly, we did it in a way that prioritized user safety alongside technical effectiveness.
Building a formal methods lab at Kaspersky required expertise and a certain vision. What inspired you to prioritize formal methods, and how did you build the team for this unique focus?
Kaspersky OS faced an interesting challenge: core OS components, like the IPC mechanism, had been designed for static embedded environments but needed to be evolved for dynamic systems like smartphones. Traditional development approaches were too expensive and risky for such fundamental changes.
What really drove our approach was realizing that we needed a way to validate complex designs before committing significant engineering resources. Most formal methods initiatives focus on complete verification, which requires extensive tooling and training. Instead, I proposed something different: a lightweight modeling approach that would let us rapidly prototype and validate critical algorithms.
The idea would work by finding the right people. I knew we wanted a person who had deep systems expertise, both theoretical and practical. I recruited a senior specialist who worked at Intel doing CPU simulation and Huawei doing Virtual Machines-someone who knew how to connect the dots from formal methods theory to systems engineering reality.
Getting the organizational buy-in was equally critical. I developed a comprehensive proposal that showed how this approach would speed up development while laying the foundation for automotive certification, which was a key business goal. In detailed discussions with the technical director, chief project manager, and finally Kaspersky’s board, we were able to show how formal methods could solve immediate engineering challenges while opening up new market opportunities.
In the lab, we focused on two critical subsystems: kernel IPC mechanism and security monitor. Using lightweight formal modeling allowed us to quickly validate the design without getting stuck in heavy verification toolchains, thus being able to improve the core OS architecture while keeping up the development velocity.
The NLP-based analysis for community health metrics you developed used RoBERTa. Can you describe how you identified and tested hypotheses about community health?
That was a classic social network analysis problem; I find they always are fascinating puzzles in and of themselves. My methodology tends to kick off with lots of exploratory data visualization-simply plot everything you could think of, and it is astounding what will jump out at you when viewing the data through different lenses.
What happened in one of the communities we studied really jumped out: we saw a 10% drop in messages classified as ’hopeful’ and a corresponding rise in ’apprehensive’ messages, perfectly correlated with a significant real-world event affecting the community. When you see such a perfect correlation, it’s tempting to run with it immediately.
But that’s exactly when you need to be most skeptical. My approach was to actively try to disprove our findings. I brought in a colleague specifically to challenge these apparent correlations. They asked great questions: Had we controlled for changes in the total volume of messages? Were we seeing the same people expressing different sentiments, or had the active user base shifted? Could this be a regular seasonal pattern rather than something unique to this period?
Only after a hypothesis underwent thorough scrutiny would we proceed to formal quantitative validation using statistical models. This kept us from over-interpreting what might have been noise in the data.
We did find some interesting patterns that stood up to this scrutiny: for instance, joyful posts would consistently generate the most positive responses, and angry posts generated the most negative. This kind of validated insight was what community managers needed in order to understand how emotional contagion played out in their spaces.
While at eQualitie, you had been working on a distributed web cache for censorship circumvention. What were the major technical challenges you had to overcome, and how did that shape your views about decentralized systems?
The core technical challenge of building CENO’s distributed cache system was to create something that would work reliably under serious constraints. We were essentially building a caching system for the worst possible conditions: low-performance devices, flaky networks, and users who might lose connectivity at any moment.
What made this particularly complex was having to bridge three very different worlds in our protocol stack: we had to interface with the fast-moving libp2p ecosystem, which was constantly evolving with new features; we had to maintain compatibility with more conservative Tor/I2P protocols; and we had to ensure everything worked smoothly with Firefox Mobile’s frontend. Each piece moved at its own pace and had different security assumptions.
That’s where the “aha” moment came in: We can turn traditional content delivery networks inside out. Instead of having central caches that could be blocked, every user’s device becomes part of the distribution system. The fascinating thing was, it actually makes the network stronger with more users-each new participant added storage and distribution capacity to the system.
One of the trickier elements of the whole design was the signature scheme for cached content, since we needed to prevent tampering with the cached pages, while at the same time allowing the user to perform the verification of content piece by piece without having to wait for a download to complete. This led us to a novel scheme of block-wise independent verifiable signatures.
Working on this project really changed the way I think about decentralized systems. The most important insight to come out of it wasn’t about removing central points of failure; it was about the design of systems that naturally get more robust as they grow. As you build with that in mind, you end up with architectures which are remarkably resilient from the point of view of the disruptions that we were trying to solve for.
As the team lead of the data science team at Profilum, you optimized algorithms that predict job skills relevant 10 years into the future. What are the methodologies or data sources that made the most impact in this ambitious project?
The key insight which made this project feasible was realizing that 10 years isn’t actually that long in terms of technology adoption cycles. When people hear ’10-year prediction,’ they often imagine we’re trying to predict completely unknown future technologies. But in reality, most major technological shifts follow surprisingly predictable patterns from initial hype to actual market impact.
Look at any transformative technology-solar power, electric vehicles, smartphones, CRISPR-and you see a similar pattern. The human capital required for these technologies tends to show up in job postings well in advance of the technology hitting mainstream economic impact. Tesla was hiring battery engineers and posting jobs about electric powertrains years before EVs were a serious force in any market. Firms also began searching for iOS developers and mobile UX designers in the run-up to when the smartphone app economy surpassed all industry expectations.
We designed our prediction methodology around this insight. By scraping the biggest job boards, you will be able to track not just current demand but also early signals of future market shifts. When you analyze the vacancy data in this way, you start seeing really fascinating patterns: Certain companies and regions really do post job requirements 3-5 years ahead of wider market adoption.
Under the hood, it was actually quite elegant. We designed a system capable of clustering related skills and monitoring their movement through the various stages of the hype cycle. Analyzing how skill requirements and compensations changed over time, we were able to discern which early-stage technologies had begun following patterns similar to the previous successful transitions.
What made this particularly powerful was our ability to distinguish between pure hype and genuine market traction. For instance, we could see how the skills related to blockchain evolved from cryptocurrency-focused roles in 2017 to enterprise distributed systems roles in later years-a track of technology maturation from speculative to practical applications.
One of the most interesting things in this work was observing how traditional roles started to incorporate new technologies. It is pretty cool when you see a conventional manufacturing job listing requirements for digital twin expertise or a traditional finance role asking for smart contract experience. That is often a much stronger signal of long-term change than pure technology roles.
You’ve contributed both to blockchain development and cybersecurity, such as maintaining a DSL-to-C compiler at Kaspersky. How do you balance the fast-paced demands of blockchain innovation with the precision required in cybersecurity?
In my experience, this is actually mostly a management problem, not a technical one. When you’re building critical infrastructure, like compilers or security tools, you need rapid innovation and rock-solid reliability. The key is creating the right foundation.
Success has come, I feel, from three core principles: First, pick your core competency and build it right-for instance, with our compiler work at Kaspersky, heavy investment in testing and modeling of the most critical components was a priority. Second, hire talented engineers who understand the need for speed and the cost of mistakes. And third, use process and culture to maintain discipline-such as having regular security review cycles even in rapid development pushes.
This lets you partition your work effectively: You can move fast on new features, while maintaining iron-clad guarantees around your security-critical core. The trick is being very clear about which components need which level of scrutiny.
Your work at multicore.cafe includes a genAI-powered copyrighting pipeline and a retrieval-augmented chatbot for health queries. How do you approach integrating cutting-edge AI into practical applications?
Well, having worked as a consultant with organizations across many different fields, I have seen that many of them come to me from the same starting point. They have lots of expertise in their domain, their processes, their customers, and workflows. But often, they lack the deep technical understanding to leverage cutting-edge AI. And it is the same thing with the most innovative AI researchers; they might be experts in bleeding-edge technology, but they actually have a rather limited understanding of the operational context their tech has to fit into.
So, the first thing I always do is listen. A lot. It’s a kind of “knowledge transfer” that goes both ways. We need to truly understand the specific problem they’re trying to solve and also make sure they understand the potential, but also the limitations, of any AI technology.
At multicore.cafe we never lead with “Hey, let’s add some AI!”. We look at the specific tasks the clients needed help with-some of the latest examples are creating compelling copy, and answering frequently asked questions about health. Then it’s about figuring out which problems really need AI, and then choosing from a very wide range of models and techniques to create a practical solution that fits the problem at hand.
The mission for our AI-powered copywriting pipeline was rather specific: speed up the process of creating high-quality, engaging marketing content. The chatbot for health queries? We zeroed in on retrieval-augmented techniques that ensure users get reliable, factual information. We’re not trying to build a general-purpose AI here; we’re trying to solve very specific problems.
This collaborative approach is key – it’s about creating AI that’s not just technologically impressive, but actually useful in the real world, and works in synergy with an existing process.
In your role as a senior performance engineer, you’ve optimized compilers and high-throughput systems. What is the most complex optimization you’ve tackled, and what insights did it provide?
One fun optimization challenge I can talk about is building a high-throughput proxy router for testing of a CDN. The requirements were pretty specific: transparently proxy traffic through a pool of 500,000 intermittently available proxies worldwide, maintain sticky routing, and handle 10,000 connections per second-all while keeping the details of proxies opaque to the client.
A colleague had an initial prototype done in Python, which gave us a baseline. Profiling immediately revealed a few bottlenecks: the implementation was very conservative with locking patterns, and we were seeing huge kernel contention. Each proxy connection setup was creating a new subprocess and at our target throughput that meant thousands of context switches per second – far more expensive than the actual routing logic itself.
The solution was remarkably straightforward once we identified the core bottleneck. I rebuilt the system in Haskell to take advantage of its n:m threaded runtime, replaced subprocess calls with a native C FFI implementation for proxy connections, and implemented an efficient streaming pipeline using conduit. The architectural shift reduced our per-connection overhead from seconds under load to under 100μs.
Initial benchmarks still showed memory growth under load, but GHC’s profiling tools made the space leaks obvious — we were accumulating things in our connection handling logic. Adding strict evaluation in a few key spots resulted in memory usage stabilizing at under 5MB per client.
Although that might sound like a complicated rewrite, the final implementation was actually pretty compact-about 800 lines of Haskell and 200 lines of C FFI code. This case reinforced a lesson I’ve seen time and time again: if you correctly identify the performance bottlenecks, the solutions often become obvious.
With experience in Haskell and formal methods, how do you advocate for the adoption of functional programming in broader engineering contexts?
I don’t think functional programming needs much advocacy these days. It’s kind of like atheism – we argued about it in the 2000s and won. Functional programming, brought on by React, Kotlin, LINQ and JAX, is the norm and not the exception these days.
What’s fascinating is how this happened through natural evolution from academic exploration to industrial adoption. That’s what academic computer scientists do: they do the necessary work of design space exploration, investigating the myriad ways of doing things, working out the theory, and showing that it is possible. At which point practitioners take such well-thought-out ideas and craft industrial-grade tools to solve real problems. React, for example, took well-understood FP concepts and turned them into a practical model of UI development. TypeScript showed how decades of type theory research could make JavaScript development more robust at scale.
I feel that engineering paradigms tend to follow demand. When our teams needed to deal with concurrency better, we got ergonomic concurrent runtimes such as Go and Kotlin. When front-end development grew complex enough, we got React’s functional approach to UI. Yet all of these were not invented in a vacuum; rather, they were created by practitioners adapting and putting together ideas which academics had already thoroughly investigated.
That is why I think experimentation and innovation in research in the field of programming languages should be encouraged. Those academic explorations, even if they do not immediately result in practical applications, give a rich set of well-understood ideas that practitioners draw upon when solving real-world problems. We need people digging into new abstractions and approaches today so that engineers have papers to crib from tomorrow.
