Emil Opachevsky, Founder, Cyincore

Emil Opachevsky is a cybersecurity practitioner with 14 years of experience across offensive security and incident response. He runs Cyincore, a consultancy focused on offensive security, DFIR, and intelligence, and is also building an AI-native platform for digital investigations. In this interview with Forensic Focus, he shares his views on AI, investigative workflows, and the challenges facing practitioners today. Emil, tell us about your company, Cyincore, and the AI-native platform you’re building for digital investigators. Cyincore is a cybersecurity company I founded that focuses on offensive security, DFIR, and intelligence work. Over the years, I’ve run red team engagements, led incident response cases, and forensics cases, and today I manage our security expert team at Cyincore. That hands-on work, doing real investigations and seeing the same bottlenecks over and over, is what led me to start building a proprietary AI-native forensics platform that we use to deliver investigations. The idea came directly from doing investigations myself and watching the same pattern repeat. Analysts spending 80% of their time on mechanical work, parsing evidence in one tool, searching a timeline in another, manually correlating findings across five or six windows, copy-pasting IOCs between tools, then spending two to three days writing the report at the end. The actual investigative thinking, the part that requires human judgment, gets maybe 20% of the analyst’s time. What we’ve built flips that ratio and cuts down the investigation timeline significantly. Evidence goes into the platform, gets parsed and normalized, a timeline and entity relationship graph are built, and then an AI agent actually investigates the case alongside our analysts – it queries the data, follows leads, documents findings with proof items tied to source evidence, and drafts the report. Our investigators’ role shifts from doing everything manually to supervising, guiding, and making the judgment calls that matter. The platform is built around the idea that the forensics expert and the AI agent share hypotheses together, research together, and come to conclusions together. It’s not a “please do the work for me” solution – it’s a collaboration system that knows the strengths and weaknesses of humans and AI agents and builds upon that. Get The Latest DFIR News Join the Forensic Focus newsletter for the best DFIR articles in your inbox every month. Unsubscribe any time. We respect your privacy - read our privacy policy. Where do current forensic workflows fall short, and where can AI genuinely improve them? The biggest problem is fragmentation. A typical investigation today involves many separate tools. You parse HD evidence in one, parse memory in another, build a timeline in a separate viewer, search logs somewhere else, check threat intel in another browser tab, take notes in a text editor, and write the report in Word. Nothing talks to anything else. The analyst is the integration layer – and that’s an incredibly expensive way to run an investigation. The second problem is scale. FBI-reported cybercrime losses hit $16.6 billion in 2024, up 33% year over year. The Verizon DBIR tracks over 10,000 confirmed breaches a year. Meanwhile, the average forensic investigation still takes 26 days. Law enforcement digital forensics units have a median of 3.5 investigators, and over half of agencies report that their backlogs are getting worse. The demand for investigations is growing at roughly 20% per year. The forensic workforce is not keeping pace, and the tooling is not advancing fast enough. Where AI genuinely helps is in the mechanical work that consumes most of an analyst’s day – parsing and normalizing evidence, correlating events across data sources, identifying patterns in large datasets, and drafting reports. These are tasks that benefit from speed and consistency, not human intuition. A good AI system can query a timeline of hundreds of thousands of events, cross-reference entities, and surface the twenty events that actually matter – in minutes instead of hours. But here’s the key – none of that replaces the investigator. The AI surfaces findings, but every one of those findings needs to go through the analyst. They review the evidence behind it, decide if it holds up, and either confirm it, adjust it, or throw it out. It’s a collaboration – the AI does the heavy lifting on data processing and pattern recognition, and the human brings the judgment, the case context, and the experience to decide what actually matters. The right model isn’t AI doing the work for you. It’s AI investigating alongside you, with the human making the calls on what’s relevant, what supports the client’s needs, and what goes in the report. How should the industry think about chain of custody and auditability when AI becomes part of the investigative process? This is one of the problems I think about most, because it’s foundational to everything else. A forensic finding that can’t be traced back to source evidence is worthless in court – and that’s true whether a human produced it or an AI did. When it’s a human investigator, the chain of custody is relatively straightforward. The analyst examines evidence, takes notes, documents findings, and writes the report. If challenged, they can explain their process on the stand. When an AI is part of the investigation – querying timelines, running forensic tools, documenting findings – you need a much more rigorous system because the AI is potentially taking hundreds of actions per investigation, and every single one needs to be traceable. The way I think about this is in three layers. First, an append-only, tamper-evident audit log that records every action in the investigation – evidence intake, every tool the AI used, every finding it created, every human approval or rejection. If any entry is altered after the fact, the integrity of the entire log should be broken in a verifiable way. This proves what actions the investigators and the AI took during the analysis. Second, provenance chains. Every finding needs to trace back through a verifiable path – the fact in the report points to proof items, each proof item points to a specific artifact or event in the case data, and that artifact traces back to the original source evidence. You should be able to verify at any point that the underlying data hasn’t changed since the finding was created. This proves that the finding wasn’t hallucinated – it’s tied to a real evidence-to-artifact-to-event chain. Third, it all needs to hold up in court. In the US, that means meeting the Federal Rules of Evidence – you need to be able to authenticate that the evidence is what you say it is, show that your records were kept reliably and systematically, and demonstrate that your methodology is sound and reproducible. None of that is new for forensics practitioners, but it takes on new urgency when AI is in the loop. The court can challenge whether an AI-assisted investigation maintained proper chain of custody – and you need to be able to answer that clearly. The forensic community has spent decades establishing chain of custody standards for physical and digital evidence. We need to extend those same standards to AI-assisted workflows – not relax them. How serious is the hallucination problem when AI is used in forensic work? It’s very serious, LLMs hallucinate, it’s a fact. That’s not a bug that will be fixed in the next model version – it’s a fundamental characteristic of how these systems work. They generate plausible outputs based on patterns in training data. In most applications, a hallucination is an inconvenience. In forensic and in any other factual work, it can be catastrophic. Consider what a hallucination looks like in a forensic context. The AI reports that a specific registry key was modified at a specific time – but that registry key doesn’t exist in the evidence. Or it attributes lateral movement to a user account based on patterns it learned during training rather than actual events in the case data. Or it fabricates a file path that ends up in a report submitted to a court or a client. These aren’t hypothetical scenarios. Anyone who has worked with LLMs on technical tasks has seen this behavior. The model confidently presents fabricated details as fact, often with enough surrounding context that it looks completely plausible. In a forensic workflow, where the analyst is reviewing dozens of AI-generated findings, a well-constructed hallucination can easily slip through. The solution has to be architectural, not procedural. You can’t just tell analysts to “double-check everything” – that defeats the purpose of using AI in the first place. The platform itself needs to enforce that every finding the AI produces is backed by verifiable evidence. That means requiring proof items that reference specific, real artifacts in the case data, with integrity hashes that can be verified. If the AI claims a registry key was modified, the system should require a proof item pointing to the actual registry data – and that reference gets validated before the finding is accepted. The outcome is that every fact is verified by a human, and the proofs that back it are verifiable in the evidence chain. The hypothesis-versus-fact distinction matters here too. There’s nothing wrong with an AI generating a hypothesis – “based on these indicators, this could be lateral movement via PsExec.” That’s useful investigative thinking. But the system needs to enforce a clear boundary between what the AI suspects and what the evidence actually shows. In a well-designed system, those are different objects with different statuses, and a hypothesis cannot appear in a final report until a human has reviewed the supporting evidence and promoted it to a confirmed fact. Investigations depend on context and human judgement. Where do you see the right balance between AI assistance and investigator oversight? The balance comes down to a simple principle: in a perfect scenario, the AI investigates, humans decide. An AI agent can do an enormous amount of useful work in a forensic investigation. It can parse and normalize evidence across dozens of artifact types. It can build a timeline of hundreds of thousands of events, query it for patterns, and surface anomalies. It can follow entity relationships – this user logged into this host, which ran this process, which connected to this IP. It can run forensic tools against evidence in an isolated environment. It can document what it finds and draft a report. In our investigations, we see this daily. What it cannot do is decide what matters. Is this lateral movement pattern relevant to the investigation scope, or is it authorized admin activity? Does this evidence support the client’s legal theory? Should this finding be included in the report, or is it a distraction? These are judgment calls that require understanding of the case context, the client’s needs, and often the legal framework – things that require a human investigator. The way to enforce this is through human-in-the-loop review at the point where AI findings become case facts. The AI proposes, the human disposes. Every finding the AI creates starts as a proposal. The investigator reviews the supporting evidence, decides whether to confirm it, modify it, or reject it entirely. This isn’t just a workflow preference – it’s a safety mechanism. It ensures that no AI-generated content enters a final deliverable without human review and approval. The other piece that matters is persistent investigation memory. Real forensic cases run for days or weeks. If your AI loses context between sessions, which is what happens with most chat-based AI tools, you lose continuity. The investigator has to re-explain the case background, re-establish what’s been found, and re-orient the AI every time they sit down to work. That’s not a minor inconvenience – it degrades investigation quality because the AI can’t build on its previous work. This is something we built into our platform early on – persistent, case-scoped memory so the AI understands the full investigation context every time the analyst picks it back up. What should practitioners ask vendors before trusting AI-powered forensic tools in real casework? There are a few questions I’d consider essential. First, can you trace every AI-generated finding back to source evidence? If the vendor can’t show you a provenance chain from a finding in a report all the way back to the original evidence, with integrity verification at each step, that’s a problem. “The AI analyzed the data” is not a chain of custody. Second, how does the system handle hallucinations? Not “our model is very accurate” – specifically, what architectural controls prevent a fabricated finding from entering a report? Does the system require proof items backed by real, verifiable evidence? Can the AI create a finding that references data that doesn’t exist in the case? If the vendor hasn’t thought about this at the architecture level, they haven’t thought about it enough. Third, is there a complete audit log, and is it tamper-evident? You need to be able to show, for any investigation, exactly what the AI did, what tools it used, what it found, and what the human investigator approved or rejected. If that log can be edited after the fact, it’s not an audit log. Fourth, what happens when the AI is wrong? Not if – when. Does the system make it easy for the investigator to reject AI findings, correct them, and document why? Is there a clear distinction between AI-generated hypotheses and human-confirmed facts? The tool should make it natural to disagree with the AI, not create pressure to accept its output. Fifth – where does the data go? Forensic evidence is some of the most sensitive data that exists. Practitioners should understand whether evidence is being sent to external APIs, whether the LLM provider retains any data, and what the isolation model looks like between cases and between clients. And finally – does this tool make my analysts better, or does it just make them faster? Speed without accuracy is dangerous in forensic work. The right AI tool should increase throughput while maintaining or improving the quality of the investigation. If it just produces findings faster without giving the analyst the ability to verify and understand those findings, it’s creating risk, not reducing it. And finally, what do you enjoy in your spare time? I like to go on walks and listen to audiobooks. I have ADD and find it hard to just sit and read – so this is my way of unplugging while still feeding curiosity. I’m also a bit of a fan of film and television. I don’t just watch – I try to study how stories are structured, how tension is built, how characters are revealed through choices rather than exposition. I have a lot of ideas for great TV shows, and every now and then, I’ll sit down and try writing a pilot episode. Maybe in my next life – for now, I keep focusing on forensics and cybersecurity.