Security Researchers: Digital Fighters Series
Sweet Security: “The speed belongs to the tool; the judgment does not”
Omer Nissim, Security Researcher at Sweet Security, discusses why the future of cybersecurity is more human than ever, as part of CTech’s Security Researchers series.
"You're handed a problem where the answer isn't documented anywhere and the only way through is to understand the system more deeply than the people who built it," explains Omer Nissim, Security Researcher at Sweet Security. Nissim arrived at Sweet after six and a half years as a cyber security specialist in the Special Operations Division, followed by a year at NVIDIA as a software architect for AI infrastructure.
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.
Reflecting on the challenges facing the security research industry as a whole today, Nissim explains that the field isn't suffering from a lack of telemetry. "Nobody is missing the events," he notes. "They're missing the story the events add up to."
You can read the entire interview below.
ID Card
Company name: Sweet Security
Founders: Dror Kashti (CEO, Brig. Gen. ret., former CISO of the IDF), Eyal Fisher (CPO, Col. ret., former head of the Cyber Department at Unit 8200), Orel Ben-Ishay (VP R&D, former cybersecurity R&D group leader in the Special Operations Division)
Year of founding: 2023
Current number of employees: ~120 across Israel and the US
Company Description:
Sweet Security is a runtime-first cloud and AI security company. Sweet's platform deploys lightweight eBPF-based sensors that give security teams live visibility into what is really executing in their cloud, and unifies that with the cloud control plane, identity, API and vulnerability layers into a single detection and response picture. Sweet Attack, our AI red-team agent, continuously tries to chain the environment's real weaknesses into working attack paths and reports only the ones that actually hold up.
About Sweet Security’s Security Research Team:
The team is larger than people tend to assume for a company our size, and it's split into two groups: infrastructure and research.
Infrastructure builds the pipeline and the data platform everything else stands on — the systems that ingest and process cloud telemetry at volume and make it possible to evaluate behavioral logic on a live stream. Research does the adversary work: understanding how attacks actually unfold in cloud and Kubernetes environments, and turning that into detection, response and offensive validation.
The split matters because those are genuinely different disciplines. What's common across both groups is the caliber of the people: strong individual contributors, all with a deep security-oriented background.
What is your background in cyber, and what led you to specialize in security research?
I spent six and a half years as a cyber security specialist in the Special Operations Division. That's where the specialization really comes from — not from a decision to "go into research," but from the fact that the work itself was research, and I found I liked the specific kind of difficulty it involves. You're handed a problem where the answer isn't documented anywhere and the only way through is to understand the system more deeply than the people who built it. That's the part I enjoy, and it turns out to be the same skill the cloud demands.
After the army I spent a year at NVIDIA as a software architect on one of their flagship AI infrastructure projects. Working on infrastructure at that scale teaches you what "high volume" actually means, and why a piece of logic that works on a laptop can be worthless in production. Detection engineering has the same shape, and it's two hard problems rather than one: it is genuinely difficult to build logic that correlates identity, control plane, and runtime into a meaningful picture. That logic must also operate over massive live event streams without generating excessive cost or noise.
What pulled me to Sweet and to detection specifically is something you notice quickly once you spend enough hours inside CloudTrail, Azure Activity Log and managed identity sign-in logs: almost everything an attacker does in the cloud is already recorded. Nobody is missing the events — they're missing the story the events add up to. That's a research problem, and it's the one I wanted to work on.
What does your security research team look like in action?
Our output isn't a report, it's logic running in production for customers. The team owns three things: the detection that catches an attack, the response that stops it, and the offensive validation that finds the attack path before anyone else does. Research runs as a loop: study how attackers actually operate in cloud and Kubernetes, then let what we see in the wild drive the next round.
We pick topics from three places: patterns repeating across customer environments, telemetry gaps where adoption is outpacing monitoring, and live threats that jump the queue.
The newest piece is Sweet Attack, our AI red-team agent. It continuously chains weaknesses in a live environment into real attack paths, and throws out the ones that don't hold up. Same knowledge as detection research, pointed the other way.
Keeping up is a challenge in its own right. New vulnerabilities and threats arrive relentlessly, and the hard part has never been seeing any single piece, it's gluing them into one story fast enough for it to matter.
We don't split detection, response and offensive validation across separate people, either. You can't write good identity detection without understanding what the workload was doing at the same moment.
How does the research team influence your company at large?
Research is not a satellite function here. It's upstream of the product, and in places it is the product. The detection content, the response logic and the attack paths Sweet Attack validates are all things that bring direct value to customers, so research velocity translates to product velocity almost one to one.
Day to day it shows up in three ways. In practice, the research team dictates a large share of the growth missions in Detection & Response: what we can catch next quarter, and what we can safely act on automatically, follows from what the team is investigating now. It feeds platform requirements backwards into engineering: when research concludes that a detection needs some live behavioral state for every identity in an environment, that becomes a data platform requirement, not a rule. And through Sweet Attack it shapes the offensive side of the product, which is the newest and probably the clearest example of research becoming a feature rather than informing one.
There's also an outward-facing effect. Research is how a security company earns the right to be believed by practitioners. CISOs don't buy a feature list; they buy the peace of mind that the people building the product understand the attack better than they do.
What has been your team’s most significant security discovery to date?
The one I'd point to came out of Sweet Attack, and it's a complete unauthenticated-to-cloud-admin chain in a live environment.
It started with a Server-Side Request Forgery (SSRF) in a customer-facing application. On its own it was close to worthless, a blind SSRF, no response coming back, the kind of finding that gets filed as low severity and forgotten. But a blind SSRF that can issue POST requests inside the cluster is a different animal, because of what else was running in there: an internal cluster management tool, reachable without authentication, that executes actions when it receives a POST.
Chaining the two turned a dead-end web bug into code execution on a pod, and that pod's identity carried permissions across the wider cloud environment. Unauthenticated HTTP request to cloud admin.
My favorite part is the reconnaissance step. To trigger the internal tool we needed the pod's name, which is randomized; nothing to guess, nothing readable from outside. That tool ships with an AI assistant. So we asked the assistant what the pod was called, and it answered. The target's own AI handed over the one piece of information standing between the outside world and the whole environment.
That chain is the best explanation I can give of what the team does. There was no zero-day in it. Every individual piece was low severity or working exactly as designed. The attack only exists if you look at the environment the way an attacker does, across application, cluster, and cloud at once.
Who or what is your 'Moby Dick'?
The attack that never touches a workload. No malware, no binary, no process to catch: just a chain of perfectly authorized API calls made by a non-human identity that has more permission than anyone realized, moving from a compromised token to data, entirely inside the control plane. There is nothing to reverse engineer. The only signal is the relationship between the identity, the action and the moment. Catching that reliably, and early enough in the chain to matter rather than at exfiltration, is the thing I most want to solve.
The second-order version is arriving fast: the same problem with AI agents in the middle. An agent with broad permissions and an MCP server nobody threat-modeled is a non-human identity with an unpredictable decision-making process attached to it. That's the next hunting ground.
How would you characterize the competition between research teams today?
Sharp, and mostly healthy. Israel in particular has an unusual density of cloud security research teams, and there is a real race to publish first on a live campaign — which does create some pressure toward speed over depth, and occasionally toward inflating a finding into a named vulnerability with a logo.
But the competition that matters isn't for headlines, it's for being right. There's also a genuine cooperative layer underneath it: when a supply chain campaign breaks, teams from competing vendors share samples and IOCs within hours, because the alternative is worse for everyone. I'd describe it as competing on publication and cooperating on defense, and I think that's the correct arrangement.
The healthiest form of the competition is the one you can measure: not who published, but whose detection actually fired in a customer environment before the damage happened.
What is your take on the future of the human security researcher?
I'd split this into four, because "AI helps us work faster" is the least interesting part of the answer:
- AI as a force multiplier in research. Deobfuscating scripts, first-pass triage of samples, drafting and reviewing detection logic. I use it daily. But our rule is that nothing reaches production without human review. AI might make mistakes, and often the mistake is that it's too specific: it locks onto the detail in front of it and draws a conclusion that's narrower than it should be, because it doesn't have the full context of how the environment actually behaves or what normal looks like there. The speed belongs to the tool; the judgment does not.
- AI as a new attack surface. This is what actually changed our work plan. That’s a category that simply didn't exist two years ago: Bedrock, Vertex, model-provider API keys, MCP servers, autonomous agents with cloud permissions. A leaked OpenAI key is now a directly monetizable asset for an attacker. An MCP server with broad scope is exactly the kind of component that gets deployed fast, before anyone writes a threat model for it. That's net more research work for humans, not less.
- AI on the attacker's side. It lowers the barrier to entry. The result isn't mainly more sophisticated attacks, it's more volume and more variants of the same attack. Which is an argument for behavioral detection over signatures.
- AI as a researcher on our side. This is the part I'd point to as the real answer to the question. Sweet Attack is an AI agent doing work that used to be a one-off human engagement. A red team engagement happens twice a year; an agent does it continuously. But note what the humans did there: we didn't automate the researcher, we encoded how a researcher reasons and then pointed it at a scale no human could cover. The agent is fast and tireless and has no taste. Deciding what constitutes a valid attack path, what evidence proves it, and what's worth a customer's attention is still entirely ours.
So my honest read: AI is eliminating the parts of the job that were never the job. What remains — deciding what's worth investigating, knowing which anomaly is a story and which is a template misconfiguration, and being accountable for what wakes someone up at 3am or gets terminated automatically in production — is more human than ever, and there's more of it than there used to be.
