Security Researchers: Digital Fighters Series
Conifers: “The attacker can walk away, and that’s what we’re least ready for”
Ido Shtrauch, Security Research Team Lead at Conifers AI, details how threat actors are adapting to a world where companies use AI to analyze their security alerts, as part of CTech’s Security Researchers series.
“The attacker can walk away, and that is what I think we are least ready for,” says Ido Shtrauch, Security Research Team Lead at Conifers.ai. “The agent finishes the job on its own. It will also write the record.” Conifers is an agentic AI SOC startup that emerged from stealth in January 2025 and is headquartered in Dallas, Texas, with its research and development operating out of Tel Aviv. Shtrauch describes the hijacking of a company’s own AI systems as his “Moby Dick”, an attack he hopes his team will be the first to catch. “Catching that is the dream, and it is hard because a hijacked agent and a busy one look the same,” he warns.
Within Israel’s cyber companies are small, highly specialized teams trained to think like attackers, find vulnerabilities and stay ahead of a threat landscape increasingly accelerated by AI. In this series, we meet the individuals and teams who make up this frontline of cyber: the digital fighters.
“Everyone here can take a big, loosely defined problem and come back with a method that works on real customer data,” says Shtrauch of his research team of four. “You need to understand attackers, understand telemetry, and have the discipline to prove a result instead of claiming it. You can’t hire that in volume.” Personally, he shares, “what pulls me in is the problem where data is not the constraint: it is all there, and the difficulty is what it means.”
You can read the entire interview below.
ID Card
Company name: Conifers.ai
Founders: Tom Findling (Co-Founder & CEO), Mark Kurman (Co-Founder & CTO), Alon Yotvat (Co-Founder & CPO)
Year of founding: 2024
Current number of employees: ~40
Company Description:
Conifers builds CognitiveSOC, an agentic AI SOC platform. It connects to the tools a customer already has, including Microsoft Sentinel and Defender, CrowdStrike and Splunk among over 90 integrations, and investigates their alerts the way a senior analyst would. It pulls the related telemetry, groups what belongs together, works out what happened, and delivers answers with the evidence behind them.
Queries run against each source in its own native syntax, so data stays in its original location and is never copied to a central store. Every conclusion ships with its reasoning trace and the queries and responses it stands on, because no SOC can act on an answer it can't check.
The goal is a SOC where the queue is no longer the job, analysts spend their day on decisions and on adversaries, and how deep an investigation goes stops depending on how much time the analyst happened to have.
About Conifer AI's Security Research Team:
There are four of us: me and three researchers. Everyone here can take a big, loosely defined problem and come back with a method that works on real customer data. That mix is rare. You need to understand attackers, understand telemetry, and have the discipline to prove a result instead of claiming it. You can’t hire that in volume.
Each of us is the person to ask about an area, and nobody stays inside their area, because the challenges don’t split neatly. The person who knows the attack technique and the person who knows what it looks like in the data usually need time together at the same whiteboard.
What we build is the flow and the algorithms under it. The flow is the shape of the investigation: which steps it takes, what evidence it needs before it can state a conclusion, when to dig deeper and when to stop. The algorithms are what make each of those steps possible, and all of it has to work at the volume a real SOC produces, where every extra signal we look at costs real tokens. Each of us owns an idea from the first sentence of it to the handover to engineering, and between us we cover endpoint, cloud, and identity across many different vendor tools.
What is your background in cyber, and what led you to specialize in security research?
My background is network and protocol analysis and detection engineering, with TTP analysis running through both, and I served in a technology unit in the intelligence field. Most of my research work has been detection at scale. My deepest work is at the network level: how protocols behave in practice rather than in the specification.
The question I kept coming back to is how traffic gets fingerprinted, attributed and tied together, as well as the opposite question: what makes traffic hard to see at all. I read every detection by asking what it would take to walk past it, and that is the same question I now ask about our own investigation logic. Today the work is agentic AI for security operations: autonomous investigation, evaluating what the models really do, ground truth, detection engineering in a world where an agent does the reading.
What does your security research team look like in action?
Every piece of research we do runs through the same six stages, and each stage forces a decision before the point where we could bend it. I don’t accept a concept without kill criteria, which is our name for what would make us stop. I care about the order more than the documents, because kill criteria written after the POC succeeded looks like discipline and gives you none. We also stop things early.
Topics rarely start from a blank page. Most come to us from product as a direction rather than a specification. Turning one of those into something we can build is itself the research. Others come from the attacker side, when threat intelligence turns up behaviour our investigation logic can’t piece together, and those arrive with a clock on them. The rest we find ourselves.
Often the subject is something nobody has defined. Everyone says threat hunting, but very few will say what an autonomous system should do once you tell it to hunt, and I can usually see more than one reasonable way to build it, each failing differently. Choosing between them is a research result, not a product preference.
I start with AI: the strongest models I can get, with our own research and evaluation tooling on top, because “it looked right in the demo” is not a result. After that I leave it to the individual, since the tools change every few months.
What pulls me in is the problem where data is not the constraint: it is all there, and the difficulty is what it means. Do these two events belong to the same intrusion? What should an agent do when the evidence is unclear, which in real environments is most of the time? You cannot solve those with more data or a better model. I have to make a call about meaning that I can defend, and then show it holds on data nobody has seen yet.
How does the research team influence your company at large?
Research sits between product and engineering, and what we own is how. Product brings a direction; engineering builds and runs what ships. In between, someone must decide what the thing should do. A spec that leaves my team becomes behavior a customer sees.
We also own whether a conclusion can be trusted. Someone sets the bar for evidence, decides what the system says when the evidence does not settle the question, and decides what has to be in front of an analyst before they will act on it without doing the work again. That last part is why this is closer to product research than to research in the classic sense: the same idea needs to be right about the attacker, right about the data, and right about the person receiving it, or it is worth nothing in a live SOC.
What has been your team’s most significant security discovery to date?
Let’s start with what is not new: hiding one success inside thousands of failures. Every SOC has seen it, and nobody needs us to report it.
What we found is a change in what the noise is for. Much of the volume was not hiding anything at all. The actors had worked out something about us: companies now use AI to analyze alerts. So the flood is not camouflage. It makes us waste our tokens on nothing.
Every alert that arrives is read, enriched and reasoned about by a model before a person ever sees it, and each of those steps costs tokens, so one worthless alert gets paid for again and again. Sending it costs the attacker almost nothing. Analyzing it costs us every single time. Send tens of thousands and the company has spent its AI budget on garbage, and nothing was hidden anywhere.
What makes it hard to see is that nothing failed. Every one of those alerts was handled correctly, and every closure was the right call on the evidence. The attack is not on the detections. It is on the capacity behind them, and today a large part of that capacity is AI.
We found it by looking at the queue as a period of time instead of a list of tickets and asking what the volume as a whole was doing. So volume is not simply a fact of life to be tuned away. It is something the attacker controls, and noise is not always hygiene. Sometimes it is the weapon.
Who or what is your 'Moby Dick'?
The attack I dream of catching is the hijacking of a company’s own AI agents. Not models in a lab: the agents already inside companies, with credentials, access to tools and standing permission to act. An agent has all the access of an employee and none of the instincts.
For a defender the interesting part is not the hijack itself but what comes after it. The payload is not a file; it’s a sentence. And it needs no exploit to travel, because the next agent will read whatever the last one wrote. That is lateral movement without touching a single host, between systems built to trust each other’s output.
Then the attacker can walk away, and that is what I think we are least ready for. The agent finishes the job on its own. It will also write the record. The company’s memory of the incident becomes the attacker’s version of it, in the company’s own voice.
Catching that is the dream, and it is hard because a hijacked agent and a busy one look the same. The detection I want has to ask about authority instead of anomaly: where did this instruction come from, and what was this agent there to do. Nobody has caught one yet. I would like us to be first.
How would you characterize the competition between research teams today?
The Israeli scene is small, dense and unusually open: people move between teams, and there is a fair amount of comparing notes. Globally the AI SOC space is crowded, and it now has its own category in Gartner’s Hype Cycle, which is both a compliment and a warning.
What interests me more is that the competition has changed shape. It used to be about discovery: who publishes the CVE, who names the campaign, who gets the write-up. Discovery is turning into something you can industrialize if you are allowed near the tooling.
Discovery still matters, but in our part of the field the rare skill is proof, and that is worth more now, not less. Demos are cheap. So the teams I watch are not the ones with the loudest findings. They are the ones who also publish what did not work, which tells you far more about whether a team is serious.
What is your take on the future of the human security researcher?
I lead a team that builds autonomous investigation agents, so I get the short version of this question a lot: are we automating ourselves out of a job? No, but the job is being rearranged, and not gently.
What AI takes is the mechanical middle of research. That work used to fill days, and it used up exactly the people whose judgement you wanted somewhere else. What AI does not take is anything that means deciding what is true. Someone must define what a correct investigation looks like before a machine can be measured against it, and think like an attacker about the system we just built. Models are weak at that last one, because they are built to be helpful about the world as it is described, and attackers work in the world as it is not described.
There is also a job that did not exist five years ago: the researcher who evaluates AI systems and secures them. AI raises the floor and the ceiling at the same time. A researcher who is only a tool operator is in trouble. A researcher who can set the bar before knowing whether they clear it has never been worth more.
