Enhancing Security Operations with Real-Time OSINT Intelligence
Part One: The Environment, and What AI Is Actually For
Melissa Newberg & Agnes Boros
Edited transcript of an ISC West panel with Melissa Newberg, Global Head of Intelligence at Seerist, and Agnes Boros, Head of Product at Seerist. The conversation covers how intelligence and security teams are using AI for real-time threat intelligence, the limits of OSINT as a category, and what it takes for analysts to trust AI-generated output. Lightly cleaned for readability; the substance is unchanged. Part two will follows separately.
MELISSA: The title of this session is "Enhancing Security Operations with Real-Time OSINT Intelligence." I want to start with that word. OSINT.
There's a reason the U.S. government has been moving away from that term. The shift toward "publicly available information," or PAI, is deliberate, because OSINT implies a finished product. It implies analysis. And a lot of what we're actually talking about is raw, open-source data that hasn't been touched by an analyst yet. Calling it intelligence is doing a lot of work that hasn't been earned.
So we ran with this title, because it's the perfect setup for what we're here to talk about: the difference between information and intelligence, and why that distinction is the whole point right now.
Information is everywhere. It's the feed, the alert, the headline, the data point. Intelligence is what you do with it. The judgment, the context, the "so what." Most organizations have a surplus of one and a shortage of the other.
That's what Agnes and I work on. I'm Melissa Newberg, Head of Intelligence at Seerist. I come at this from the practitioner side. Today you're going to get two perspectives, unified under the idea that we are integrating and building together to respond to a moment where teams need to make sense of the world around them. I'll turn it over to Agnes.
AGNES: Thanks, Melissa. I'm Agnes, Head of Product at Seerist, which means I spend my days obsessing over one question: how do you build technology that actually works for intelligence and security teams when they're under pressure? Not in a demo, not in a perfect-world workflow, but at 2am, when something real is unfolding and someone has to make a call.
That's the lens I'm bringing today. Less about the theory, more about what it actually takes to build tools that earn trust in this environment.
Why "continuous pressure" has replaced episodic crisis in global security
MELISSA: Agnes is going to talk about how we build for this environment. But first I want to spend a minute on what the environment actually feels like right now, because I think it's often steeped in what are quite frankly trite phrases at this point. Unprecedented times. More chaotic than ever before. We say and hear these things a lot, but what actually is it?
Take the Middle East. Late February, US and Israeli strikes targeting military sites, air defense systems, leadership, simultaneously. Airspace closures across the region, impacting travelers and anyone trying to evacuate. Missile salvos intercepted, targeted toward Israel, the Gulf countries. Debris landing in Doha, Dubai, Kuwait. All of that unfolding within hours, across multiple countries, with conflicting reporting, unverified claims, and everyone with an opinion on social media layering noise on top of noise.
If you had travelers in the Gulf that night, and a lot of you probably did, that's the moment. That's when everything you've built either holds or it doesn't.
What strikes me about that situation isn't that it was unusual. It's that it wasn't. We are operating in an environment where events like that are no longer episodic. The baseline is continuous pressure. The drumbeat doesn't stop between crises. There is no between anymore.
There's also something happening within this that I call the normalization trap. Teams have absorbed so much sustained pressure that their risk tolerance has drifted up without anyone consciously deciding that. You get desensitized. You stop escalating things that two years ago would have been an immediate notification to leadership. That creeping tolerance is masking a fragility underneath.
Information isn't the problem. We have more information than any intelligence team in history. The problem is interpretation. What does this mean for us, specifically? And how fast can we answer that?
AGNES: What Melissa just described is exactly the problem we were trying to solve when we built Seerist's core architecture. The key insight for us was this: the operating environment isn't a report. It's a living, spatial picture. The question is whether your tools let you see it that way.
When you layer incident data, open-source reporting, and AI-driven analysis onto a geographic picture, something shifts. You stop looking at a list of events and you start seeing an environment. A protest movement in one city, a supply chain disruption in a port 500 miles away, and a political crisis in the capital aren't three separate line items in a morning brief. They're a connected picture that tells you something about where risk is headed.
The question isn't whether we need to adapt to this environment. It's whether we build systems that create advantage within it, or just add to the chaos.
Will AI replace intelligence analysts?
AGNES: I want to start here because I hear this question constantly, and it deserves a direct answer: is AI going to replace analysts?
No. But I want to explain why in a way that's actually useful, not just reassuring.
AI and analysts have fundamentally different jobs. When you try to use AI to do the analyst's job, it fails. When you try to use analysts to do AI's job, they burn out and miss things. The magic is in understanding which is which.
Here's how I think about the division. AI handles scale that humans can't. Collection across massive volumes of open-source data. Initial synthesis. Pattern detection. Continuous monitoring that doesn't fatigue or lose focus at hour six. That's AI's job.
Humans handle what AI genuinely cannot do. Question formulation, knowing what to actually ask. Source credibility judgments. Operating under uncertainty. Communicating confidence accurately. And most importantly, understanding what the decision-maker in front of you actually needs, which is often different from what they say they need.
The goal is AI making analysts faster and more deliberate, not creating new dependencies, and not substituting for critical thinking. That's the design principle we come back to constantly.
It's not enough for AI to solve the problem of efficiency. It has to be effective. And it can only do that if it's transparent. None of this works if the AI is a black box. If an analyst can't see where an output came from, can't interrogate the sourcing, can't trace the methodology, they shouldn't trust it. And they won't. And they'd be right not to.
We feel strongly about this at Seerist. We have 15-plus years of human-curated intelligence and methodology that predates the AI tools we've built on top of it. That foundation matters. AI built on top of unverified, uncurated data produces confident-sounding garbage. AI built on a rigorous foundation produces something you can actually trust and act on.
MELISSA: Can I jump in here, because I want to name that directly from the practitioner side.
When a new tool lands on my desk, any tool, my first question isn't "is this fast?" It's "do I trust this?" Trust for an analyst is very specific. I don't just need the output to seem right. I need to understand how it got there.
Show me the source. Show me when it was published. Show me whether it's verified or unverified. Because if I'm taking something to my CSO, or putting it in a report that's going to drive a decision, I need to be able to defend it. That's your decision advantage right there.
That's not AI skepticism. That's just how analysts are trained to think. Any tool that doesn't give me that transparency isn't going to get used. It's going to sit there while my team finds a workaround.
AGNES: And I'd add to what Melissa said: that trust is a product design problem as much as it is a data problem. You earn it through the interface choices you make. What you show, what you hide, what you surface first, and how easy you make it to go deeper when someone needs to.
What "real-time" actually means in threat intelligence
AGNES: Let's talk about what "real-time" actually means in practice, because I think it gets misused a lot.
Real-time doesn't mean a firehose. It doesn't mean routing every possible data point to every possible person as fast as possible. That's not intelligence. That's noise with a timestamp.
Real-time, done right, means a curated notification that something operationally significant to your organization is unfolding. By the time the alert reaches the operator, human judgment has already been applied. Someone, or something, with human oversight, has verified this is real. Someone has assessed that it crosses a threshold of significance and surfaced it with transparent sourcing and methodology. The GSOC operator at 2am is starting with signal, not noise. That's the design goal.
What's happening underneath that alert is the proactive collection layer. AI-driven pattern recognition, anomaly detection operating continuously across volumes no human team could parse, layered onto geographic context, fused with open-source intel. Continuous monitoring that doesn't fatigue. Doesn't miss the third hour of a slowly developing situation because attention drifted. This is the work AI should be doing, the work that used to eat up analyst hours and still left gaps because humans have limits.
This is when you shift from reactive collection to proactive threat detection. That's not a small operational difference. That's the difference between your team getting ahead of a situation and your team spending the first three hours catching up.
MELISSA: Let me make that concrete. This just happened this weekend, so it's a live example.
Early Sunday local time, there were reports that Iran attempted to target the UK-US base at Diego Garcia with missiles. This is an unusual escalation for a number of reasons: implications for the trajectory of the war, the kind of missiles Iran may actually have. We hadn't seen anything deployed with that kind of reach. It's a significant development that you really don't want to get wrong.
The alert you receive on something like that can't be the hundredth thing your GSOC sees that night. It has to be the one thing, at the right moment, with enough context to act and prepare your organization in the right kind of way. Internally at Seerist, my team of researchers made the judgment call not to alert on this as a verified breaking event until we had some certainty about it. Credibility is everything in this industry. We don't want to issue something that jeopardizes our clients' credibility if they trusted that we had verified it.
The firehose isn't intelligence. A hundred alerts isn't intelligence. One verified, contextualized, sourced notification that arrives at the right time and tells you what to do about it. That's intelligence. That's the whole job.
AGNES: Here's a principle that drives a lot of our product decisions: designing for cognitive load under pressure.
At 2am, the GSOC operator deciding whether to call the CSO does not need exhaustive context. They need orientation. Is this real, does it matter to us, what should I do right now?
Attention is finite. When someone is under pressure, every additional piece of information they have to process is a cost. The instinct in product design, and honestly in intelligence production, is to add. More context, more caveats, more data. But clarity almost always comes from subtraction, not addition.
The same capabilities that make a GSOC operator effective at 2am in a crisis are the ones that enable foresight work. Horizon scanning. Scenario work. Identifying emerging risks that haven't arrived yet. Organizations that only build for reaction will always be behind. The teams pulling ahead are asking two questions simultaneously: how fast can we make sense of this crisis, and what's coming that we should be thinking about now? The underlying architecture, verified data, sound methodology, AI-assisted synthesis, serves both.
Part two of this conversation continues with what happens after the alert lands: integration, the human-machine partnership, and why methodology has to come before technology.
Editorial note: The content above is drawn directly from a one-hour ISC West session led by Melissa Newberg and Agnes Boros. AI was used to condense and reproduce the audio into a readable article that captures the essence of the live discussion. The source recording is embedded at the top of this post.