In Conversation With... Bogdan Kireeve
In Conversation With... Bogdan Kireeve
In Conversation With... Bogdan Kireeve
In Conversation with ... Bogdan Kireeve on AI Agents and the Future of Fintech Resilience - Modernising SecOps and DevOps for Scale
The Changing Nature of Resilience
Q: Fintech platforms operate under constant pressure - from uptime expectations to regulatory scrutiny. How is the definition of “resilience” evolving as systems become more distributed and complex?
Resilience is, at its heart, an architectural problem. Solving it is harder due to these growing, multi-layered, and distributed environments that fintech platforms are built on, but they aren't insurmountable. Technologically, we are at a point where an LLM can tell you how to achieve strong resiliency across your architecture, and actually build it for you. The real differentiator, though, is people. The answer lies in genuine cross-functional collaboration across the business. In my recent book, I highlighted the importance of DevOps and DevSecOps as operational mindsets that have to be grown organically inside a business for it to truly succeed. The outcome is a clearer understanding of what your business looks like, how it runs, who is accountable, and a structured approach to everyday observability and security. Resilience is ultimately an off-shoot of that mindset - when you have the right culture and the right visibility, resilience stops being a project and becomes a natural state.
Q: What practical steps can teams take today to proactively address reliability challenges instead of constantly playing catch-up?
Automate, automate, automate. Make sure there is a minimal amount of manual work happening at any layer. Automate your infrastructure, patching, deployments, and scanning activity. From a security perspective, invest in tools that can autonomously triage and investigate suspicious findings on your behalf because the volume of alerts modern environments generate makes manual review a losing game. The numbers back this up: research shows it takes organisations an average of 56 minutes just to acknowledge an alert, and another 70 minutes to investigate it. Meanwhile, attackers with AI can develop exploits within 15 minutes of a vulnerability being disclosed. There is simply no way to win this without upskilling in AI, understanding your architecture deeply, and tailoring automation to your specific environment. The teams that are winning aren't necessarily the ones with the biggest budgets, they're the ones that have stopped tolerating manual toil.
Q: As organisations scale rapidly, what does resilience look like beyond just availability, and why is it becoming a shared responsibility across engineering, security, and operations?
Resilience is no longer something the infrastructure team or operations own in isolation. At scale, resilience means your entire organisation can absorb, adapt to, and recover from disruption. This can be a security incident, a deployment gone wrong, or a sudden spike in traffic. That requires engineering, security, and operations working from the same data and toward the same outcomes. The old model, where each team had its own tools, its own dashboards, and its own language, simply doesn't hold up when you're running distributed systems across multiple cloud providers. Shared responsibility isn't a nice-to-have, it's a requirement. And honestly, AI is one of the few things that can actually bridge that gap, because it speaks everyone's language and surfaces insights regardless of which team is looking at it.
Q: What are some of the most common misconceptions teams have about building resilient platforms, and where do you see organisations investing effort that doesn’t actually move the needle?
The biggest misconception is that resilience is a destination. You buy the right tool, run the right project, get the certificate on the wall, and you're done. Resilience is a continuous practice, not a one-time achievement. The second misconception is that more tooling equals more resilience. I've seen organisations running fifteen different monitoring products that don't talk to each other and have less observability than a team running one well-integrated platform. There’s no point investing in tools without investing in the processes and culture around them. You can have the best SIEM on the market, but if your team doesn't have a clear playbook for what to do when it fires an alert, you've bought yourself an expensive noise machine. Start with outcomes: what does "resilient" actually mean for your business, and work backwards from there.
AI Agents in Modern SecOps and DevOps
Q: We’re seeing a growing focus on AI agents designed specifically for security and operational use cases. What’s changed in recent years that’s made this shift both possible and necessary?
If you haven't been living under a rock, you've encountered the surge in LLM and AI technologies first-hand. This is a technological shift on the same order of magnitude as the internet in the 90s or the smartphone in the 2000s. The ability for an AI agent to intelligently navigate a file structure, an architecture, or a web application, and not just understand it but decide how to exploit or defend it, is something that's very hard to ignore. What’s more important is that once you've seen it in action, you don’t want to go back. What's changed is the quality of reasoning these models can perform. They can reason, adapt, and act on context they've never seen before. This is great - it can free human experts from the intellectually unchallenging work such as reports, trawling through logs and repetitive queries so we can apply our curiosity and judgement to problems that actually require it. That's not a threat to security professionals; it's a significant upgrade.
Q: How do AI agents differ from earlier automation approaches in the way they support investigation, triage, and day-to-day decision-making?
Prior to AI, automation was essentially scripted behaviour - rules-based, rigid, and entirely dependent on what someone anticipated in advance. If the scenario wasn't in the playbook, the automation didn't know what to do. AI agents operate fundamentally differently: they can reason across novel situations, correlate signals they've never explicitly been trained to connect, and adapt their approach based on context. In a modern SOC, that's transformational. Instead of waiting for a rule to fire, an agent can observe anomalous behaviour, investigate across multiple data sources simultaneously, and surface a prioritised, contextualised finding. All of this in the time it would take a human analyst to open their first query window. The shift isn't just about speed, either. It's about coverage. AI doesn't get alert fatigue. It doesn't ignore the thousandth notification of the day. And research suggests that's a very real problem: around 60% of security teams have experienced incidents tied directly to alerts that were ignored, that actually turned out to be critical.
Trust, Autonomy, and Human Judgment
Q: Tools like Dojo AI are designed to assist teams during high-pressure moments. How should organisations think about trust when AI agents are influencing security and operational outcomes?
Trust is going to be the defining criteria for teams working with AI for the foreseeable future. LLMs are highly capable - tools like Sumo Logic's Mobot are excellent at accurately correlating and detecting unusual activity at scale. But how do you know you can believe it? The answer is transparency. Good AI tools show you exactly what they're doing, why they flagged something, and how they arrived at a conclusion. This is what allows teams to verify that the steps and the results actually make sense. When the AI says "I believe this isn't Medium severity, it's Critical, and here's my reasoning," you have everything you need to make an informed call. Black box AI that relies on obscure algorithms running invisibly in the background will not be trusted by most organisations, and rightfully so. Especially in regulated fintech environments, the audit trail matters as much as the outcome. If you can't explain a decision to a regulator, you've got a problem that no amount of accuracy will fix.
Q: There’s a lot of discussion around “human-in-the-loop” models - in practice, where do you see the right balance today between automation and human judgement?
I want to be clear on one point: human reasoning and intelligence is not going away. It is being re-deployed to higher-value parts of the operational process and that's a good thing. Automation is now in a far stronger position to handle low-intelligence, high-effort work: querying across large datasets, correlating information, generating dashboards and reports, and normalising alerts. These are things machines do better, faster, and at greater scale than humans. But all of that automation serves one purpose: helping us reach better outcomes. Who spun down the Kubernetes pod at 4am? Why did this person turn off the audit log? Machines can help surface the evidence rapidly, across terabytes of data but the judgement call remains human. I think of it as this: AI handles the investigation, humans make the decisions. Get that balance right and you've got a genuinely formidable operation.
Q: SecOps and DevOps teams often work with different priorities, data, and tooling. Can AI-driven platforms help bridge that gap, or do they risk reinforcing existing silos if not implemented carefully?
The goal should be to get all operational teams working from the same data. And we are at a moment in time where that is more achievable than it has ever been. Technology like Sumo Logic provides a centralised source of truth for the entire business - developers, SecOps, DevOps, even marketing. There are no formatting inconsistencies and a universal way to extract insights: Mobot. That reduction of barriers in the technology should, if implemented thoughtfully, reduce barriers between the teams themselves. Here's a real-world example: a Kubernetes node running at 90% CPU. DevOps investigates in an observability platform but can't pivot to logs easily so they spend ages running queries. Eventually someone spots logs that look like erroneous code and raises a ticket for the SOC. The SOC, a few hours later, identifies it as a malicious script deployed to the cluster. A high-severity incident is kicked off. Time between detection and response: hours. My question is simple. Why not bring those teams into a unified data landscape from the start, where Mobot can correlate across typically siloed observability and security data in minutes, without anyone needing to write a single query? The technology is there.
Q: How important is shared visibility and context when teams are responding to incidents at scale, and what role can AI play in enabling that?
The fact is that without visibility, you are vulnerable full stop. Attackers don't care that your engineers prefer a particular observability tool or that your security team swears by a specific SIEM. Attackers exploit your data irrespective of where it lives and what interface you happen to view it through. Shared visibility is non-negotiable. You need a data lake where you can store data for extended periods at a reasonable cost, and analyse it across multiple dimensions. At scale, AI becomes equally non-negotiable because the speed and breadth at which it can query and correlate across your data is simply beyond what any human team can match. The organisations getting this right are the ones treating visibility as infrastructure, not as a reporting exercise.
Common Pitfalls and Misconceptions
Q: What are some of the most common mistakes organisations make when introducing AI into security and observability workflows?
Organisations without a clear plan for AI will struggle. A directive like "your work should consist of 40% AI" is not a plan, it's a target that sounds strategic and means nothing in practice. There has to be an outcome-driven approach, with tangible, measurable ROI. How much time will it save your team when it comes to making sense of your data? How much faster can you resolve a P1 incident compared to before? These are the questions that matter. The second common mistake is treating AI as a standalone capability rather than integrating it into existing workflows. AI dropped on top of a broken process doesn't fix the process, it just automates the chaos. And the third: underestimating the change management piece. The technology is often the easy part; getting teams to trust it, use it consistently, and evolve their processes around it is where most implementations stall.
Q: Where do teams tend to overestimate AI’s capabilities today, and where do you think its value is still being underestimated?
AI has been a remarkable asset for operational teams, but limitations do still exist. Hallucinations remain a real risk in AI output, even in highly contextualised deployments where the model has access to your actual data. The risk is greatly reduced compared to general-purpose use, but it hasn't disappeared. That's why you still need people with genuine domain expertise to verify outputs and ensure the models are performing as intended. You can't fully replace the engineer or security professional who knows your landscape, your architecture, and your business inside and out. You shouldn’t want to do that either. Regarding underestimating AI, most organisations still aren't taking full advantage of AI's ability to connect signals across siloed datasets that no human team could realistically analyse in parallel. The value sitting unrealised there is significant.
Governance, Scale, and What Comes Next
Q: In regulated fintech environments, governance and explainability are critical. What should leaders be demanding from AI-powered SecOps tools to maintain accountability and trust?
Leaders should be demanding full transparency from their AI tools. The FCA, PRA, and regulators globally are increasingly clear that black-box AI is not acceptable in high-stakes financial environments. If your AI tool cannot show you why it made a decision, you cannot defend that decision to a regulator, an auditor, or a board. Beyond explainability, leaders should demand clear audit trails, human override capabilities at every critical decision point, and documented model governance. This includes how the model was trained, what data it uses, and how drift or degradation is detected over time. Think of it this way: the regulator isn't going to accept "the AI said so" as an answer and neither should you.
Q: Looking ahead, how do you see AI agents reshaping the relationship between SecOps and DevOps, and what should organisations be doing now to prepare for that future?
The lines between SecOps and DevOps are going to blur significantly and AI is the catalyst, in a good way as we discussed before. When both teams are working from the same data, querying it through the same interface, and receiving AI-generated insights that don't care about organisational boundaries, the distinction becomes less about who owns what and more about who has the right expertise to act. Research suggests that 83% of security leaders believe AI will handle over half of SOC workloads within three years. Whether or not that number holds, the direction is clear. What should organisations be doing now? Three things: invest in a unified data platform, build outcome-driven AI governance before you need it, and start upskilling your people. The teams that will thrive aren't the ones that adopted AI the fastest, they're the ones who understood how to apply it and use it fully.
In Conversation with ... Bogdan Kireeve on AI Agents and the Future of Fintech Resilience - Modernising SecOps and DevOps for Scale
The Changing Nature of Resilience
Q: Fintech platforms operate under constant pressure - from uptime expectations to regulatory scrutiny. How is the definition of “resilience” evolving as systems become more distributed and complex?
Resilience is, at its heart, an architectural problem. Solving it is harder due to these growing, multi-layered, and distributed environments that fintech platforms are built on, but they aren't insurmountable. Technologically, we are at a point where an LLM can tell you how to achieve strong resiliency across your architecture, and actually build it for you. The real differentiator, though, is people. The answer lies in genuine cross-functional collaboration across the business. In my recent book, I highlighted the importance of DevOps and DevSecOps as operational mindsets that have to be grown organically inside a business for it to truly succeed. The outcome is a clearer understanding of what your business looks like, how it runs, who is accountable, and a structured approach to everyday observability and security. Resilience is ultimately an off-shoot of that mindset - when you have the right culture and the right visibility, resilience stops being a project and becomes a natural state.
Q: What practical steps can teams take today to proactively address reliability challenges instead of constantly playing catch-up?
Automate, automate, automate. Make sure there is a minimal amount of manual work happening at any layer. Automate your infrastructure, patching, deployments, and scanning activity. From a security perspective, invest in tools that can autonomously triage and investigate suspicious findings on your behalf because the volume of alerts modern environments generate makes manual review a losing game. The numbers back this up: research shows it takes organisations an average of 56 minutes just to acknowledge an alert, and another 70 minutes to investigate it. Meanwhile, attackers with AI can develop exploits within 15 minutes of a vulnerability being disclosed. There is simply no way to win this without upskilling in AI, understanding your architecture deeply, and tailoring automation to your specific environment. The teams that are winning aren't necessarily the ones with the biggest budgets, they're the ones that have stopped tolerating manual toil.
Q: As organisations scale rapidly, what does resilience look like beyond just availability, and why is it becoming a shared responsibility across engineering, security, and operations?
Resilience is no longer something the infrastructure team or operations own in isolation. At scale, resilience means your entire organisation can absorb, adapt to, and recover from disruption. This can be a security incident, a deployment gone wrong, or a sudden spike in traffic. That requires engineering, security, and operations working from the same data and toward the same outcomes. The old model, where each team had its own tools, its own dashboards, and its own language, simply doesn't hold up when you're running distributed systems across multiple cloud providers. Shared responsibility isn't a nice-to-have, it's a requirement. And honestly, AI is one of the few things that can actually bridge that gap, because it speaks everyone's language and surfaces insights regardless of which team is looking at it.
Q: What are some of the most common misconceptions teams have about building resilient platforms, and where do you see organisations investing effort that doesn’t actually move the needle?
The biggest misconception is that resilience is a destination. You buy the right tool, run the right project, get the certificate on the wall, and you're done. Resilience is a continuous practice, not a one-time achievement. The second misconception is that more tooling equals more resilience. I've seen organisations running fifteen different monitoring products that don't talk to each other and have less observability than a team running one well-integrated platform. There’s no point investing in tools without investing in the processes and culture around them. You can have the best SIEM on the market, but if your team doesn't have a clear playbook for what to do when it fires an alert, you've bought yourself an expensive noise machine. Start with outcomes: what does "resilient" actually mean for your business, and work backwards from there.
AI Agents in Modern SecOps and DevOps
Q: We’re seeing a growing focus on AI agents designed specifically for security and operational use cases. What’s changed in recent years that’s made this shift both possible and necessary?
If you haven't been living under a rock, you've encountered the surge in LLM and AI technologies first-hand. This is a technological shift on the same order of magnitude as the internet in the 90s or the smartphone in the 2000s. The ability for an AI agent to intelligently navigate a file structure, an architecture, or a web application, and not just understand it but decide how to exploit or defend it, is something that's very hard to ignore. What’s more important is that once you've seen it in action, you don’t want to go back. What's changed is the quality of reasoning these models can perform. They can reason, adapt, and act on context they've never seen before. This is great - it can free human experts from the intellectually unchallenging work such as reports, trawling through logs and repetitive queries so we can apply our curiosity and judgement to problems that actually require it. That's not a threat to security professionals; it's a significant upgrade.
Q: How do AI agents differ from earlier automation approaches in the way they support investigation, triage, and day-to-day decision-making?
Prior to AI, automation was essentially scripted behaviour - rules-based, rigid, and entirely dependent on what someone anticipated in advance. If the scenario wasn't in the playbook, the automation didn't know what to do. AI agents operate fundamentally differently: they can reason across novel situations, correlate signals they've never explicitly been trained to connect, and adapt their approach based on context. In a modern SOC, that's transformational. Instead of waiting for a rule to fire, an agent can observe anomalous behaviour, investigate across multiple data sources simultaneously, and surface a prioritised, contextualised finding. All of this in the time it would take a human analyst to open their first query window. The shift isn't just about speed, either. It's about coverage. AI doesn't get alert fatigue. It doesn't ignore the thousandth notification of the day. And research suggests that's a very real problem: around 60% of security teams have experienced incidents tied directly to alerts that were ignored, that actually turned out to be critical.
Trust, Autonomy, and Human Judgment
Q: Tools like Dojo AI are designed to assist teams during high-pressure moments. How should organisations think about trust when AI agents are influencing security and operational outcomes?
Trust is going to be the defining criteria for teams working with AI for the foreseeable future. LLMs are highly capable - tools like Sumo Logic's Mobot are excellent at accurately correlating and detecting unusual activity at scale. But how do you know you can believe it? The answer is transparency. Good AI tools show you exactly what they're doing, why they flagged something, and how they arrived at a conclusion. This is what allows teams to verify that the steps and the results actually make sense. When the AI says "I believe this isn't Medium severity, it's Critical, and here's my reasoning," you have everything you need to make an informed call. Black box AI that relies on obscure algorithms running invisibly in the background will not be trusted by most organisations, and rightfully so. Especially in regulated fintech environments, the audit trail matters as much as the outcome. If you can't explain a decision to a regulator, you've got a problem that no amount of accuracy will fix.
Q: There’s a lot of discussion around “human-in-the-loop” models - in practice, where do you see the right balance today between automation and human judgement?
I want to be clear on one point: human reasoning and intelligence is not going away. It is being re-deployed to higher-value parts of the operational process and that's a good thing. Automation is now in a far stronger position to handle low-intelligence, high-effort work: querying across large datasets, correlating information, generating dashboards and reports, and normalising alerts. These are things machines do better, faster, and at greater scale than humans. But all of that automation serves one purpose: helping us reach better outcomes. Who spun down the Kubernetes pod at 4am? Why did this person turn off the audit log? Machines can help surface the evidence rapidly, across terabytes of data but the judgement call remains human. I think of it as this: AI handles the investigation, humans make the decisions. Get that balance right and you've got a genuinely formidable operation.
Q: SecOps and DevOps teams often work with different priorities, data, and tooling. Can AI-driven platforms help bridge that gap, or do they risk reinforcing existing silos if not implemented carefully?
The goal should be to get all operational teams working from the same data. And we are at a moment in time where that is more achievable than it has ever been. Technology like Sumo Logic provides a centralised source of truth for the entire business - developers, SecOps, DevOps, even marketing. There are no formatting inconsistencies and a universal way to extract insights: Mobot. That reduction of barriers in the technology should, if implemented thoughtfully, reduce barriers between the teams themselves. Here's a real-world example: a Kubernetes node running at 90% CPU. DevOps investigates in an observability platform but can't pivot to logs easily so they spend ages running queries. Eventually someone spots logs that look like erroneous code and raises a ticket for the SOC. The SOC, a few hours later, identifies it as a malicious script deployed to the cluster. A high-severity incident is kicked off. Time between detection and response: hours. My question is simple. Why not bring those teams into a unified data landscape from the start, where Mobot can correlate across typically siloed observability and security data in minutes, without anyone needing to write a single query? The technology is there.
Q: How important is shared visibility and context when teams are responding to incidents at scale, and what role can AI play in enabling that?
The fact is that without visibility, you are vulnerable full stop. Attackers don't care that your engineers prefer a particular observability tool or that your security team swears by a specific SIEM. Attackers exploit your data irrespective of where it lives and what interface you happen to view it through. Shared visibility is non-negotiable. You need a data lake where you can store data for extended periods at a reasonable cost, and analyse it across multiple dimensions. At scale, AI becomes equally non-negotiable because the speed and breadth at which it can query and correlate across your data is simply beyond what any human team can match. The organisations getting this right are the ones treating visibility as infrastructure, not as a reporting exercise.
Common Pitfalls and Misconceptions
Q: What are some of the most common mistakes organisations make when introducing AI into security and observability workflows?
Organisations without a clear plan for AI will struggle. A directive like "your work should consist of 40% AI" is not a plan, it's a target that sounds strategic and means nothing in practice. There has to be an outcome-driven approach, with tangible, measurable ROI. How much time will it save your team when it comes to making sense of your data? How much faster can you resolve a P1 incident compared to before? These are the questions that matter. The second common mistake is treating AI as a standalone capability rather than integrating it into existing workflows. AI dropped on top of a broken process doesn't fix the process, it just automates the chaos. And the third: underestimating the change management piece. The technology is often the easy part; getting teams to trust it, use it consistently, and evolve their processes around it is where most implementations stall.
Q: Where do teams tend to overestimate AI’s capabilities today, and where do you think its value is still being underestimated?
AI has been a remarkable asset for operational teams, but limitations do still exist. Hallucinations remain a real risk in AI output, even in highly contextualised deployments where the model has access to your actual data. The risk is greatly reduced compared to general-purpose use, but it hasn't disappeared. That's why you still need people with genuine domain expertise to verify outputs and ensure the models are performing as intended. You can't fully replace the engineer or security professional who knows your landscape, your architecture, and your business inside and out. You shouldn’t want to do that either. Regarding underestimating AI, most organisations still aren't taking full advantage of AI's ability to connect signals across siloed datasets that no human team could realistically analyse in parallel. The value sitting unrealised there is significant.
Governance, Scale, and What Comes Next
Q: In regulated fintech environments, governance and explainability are critical. What should leaders be demanding from AI-powered SecOps tools to maintain accountability and trust?
Leaders should be demanding full transparency from their AI tools. The FCA, PRA, and regulators globally are increasingly clear that black-box AI is not acceptable in high-stakes financial environments. If your AI tool cannot show you why it made a decision, you cannot defend that decision to a regulator, an auditor, or a board. Beyond explainability, leaders should demand clear audit trails, human override capabilities at every critical decision point, and documented model governance. This includes how the model was trained, what data it uses, and how drift or degradation is detected over time. Think of it this way: the regulator isn't going to accept "the AI said so" as an answer and neither should you.
Q: Looking ahead, how do you see AI agents reshaping the relationship between SecOps and DevOps, and what should organisations be doing now to prepare for that future?
The lines between SecOps and DevOps are going to blur significantly and AI is the catalyst, in a good way as we discussed before. When both teams are working from the same data, querying it through the same interface, and receiving AI-generated insights that don't care about organisational boundaries, the distinction becomes less about who owns what and more about who has the right expertise to act. Research suggests that 83% of security leaders believe AI will handle over half of SOC workloads within three years. Whether or not that number holds, the direction is clear. What should organisations be doing now? Three things: invest in a unified data platform, build outcome-driven AI governance before you need it, and start upskilling your people. The teams that will thrive aren't the ones that adopted AI the fastest, they're the ones who understood how to apply it and use it fully.
In Conversation with ... Bogdan Kireeve on AI Agents and the Future of Fintech Resilience - Modernising SecOps and DevOps for Scale
The Changing Nature of Resilience
Q: Fintech platforms operate under constant pressure - from uptime expectations to regulatory scrutiny. How is the definition of “resilience” evolving as systems become more distributed and complex?
Resilience is, at its heart, an architectural problem. Solving it is harder due to these growing, multi-layered, and distributed environments that fintech platforms are built on, but they aren't insurmountable. Technologically, we are at a point where an LLM can tell you how to achieve strong resiliency across your architecture, and actually build it for you. The real differentiator, though, is people. The answer lies in genuine cross-functional collaboration across the business. In my recent book, I highlighted the importance of DevOps and DevSecOps as operational mindsets that have to be grown organically inside a business for it to truly succeed. The outcome is a clearer understanding of what your business looks like, how it runs, who is accountable, and a structured approach to everyday observability and security. Resilience is ultimately an off-shoot of that mindset - when you have the right culture and the right visibility, resilience stops being a project and becomes a natural state.
Q: What practical steps can teams take today to proactively address reliability challenges instead of constantly playing catch-up?
Automate, automate, automate. Make sure there is a minimal amount of manual work happening at any layer. Automate your infrastructure, patching, deployments, and scanning activity. From a security perspective, invest in tools that can autonomously triage and investigate suspicious findings on your behalf because the volume of alerts modern environments generate makes manual review a losing game. The numbers back this up: research shows it takes organisations an average of 56 minutes just to acknowledge an alert, and another 70 minutes to investigate it. Meanwhile, attackers with AI can develop exploits within 15 minutes of a vulnerability being disclosed. There is simply no way to win this without upskilling in AI, understanding your architecture deeply, and tailoring automation to your specific environment. The teams that are winning aren't necessarily the ones with the biggest budgets, they're the ones that have stopped tolerating manual toil.
Q: As organisations scale rapidly, what does resilience look like beyond just availability, and why is it becoming a shared responsibility across engineering, security, and operations?
Resilience is no longer something the infrastructure team or operations own in isolation. At scale, resilience means your entire organisation can absorb, adapt to, and recover from disruption. This can be a security incident, a deployment gone wrong, or a sudden spike in traffic. That requires engineering, security, and operations working from the same data and toward the same outcomes. The old model, where each team had its own tools, its own dashboards, and its own language, simply doesn't hold up when you're running distributed systems across multiple cloud providers. Shared responsibility isn't a nice-to-have, it's a requirement. And honestly, AI is one of the few things that can actually bridge that gap, because it speaks everyone's language and surfaces insights regardless of which team is looking at it.
Q: What are some of the most common misconceptions teams have about building resilient platforms, and where do you see organisations investing effort that doesn’t actually move the needle?
The biggest misconception is that resilience is a destination. You buy the right tool, run the right project, get the certificate on the wall, and you're done. Resilience is a continuous practice, not a one-time achievement. The second misconception is that more tooling equals more resilience. I've seen organisations running fifteen different monitoring products that don't talk to each other and have less observability than a team running one well-integrated platform. There’s no point investing in tools without investing in the processes and culture around them. You can have the best SIEM on the market, but if your team doesn't have a clear playbook for what to do when it fires an alert, you've bought yourself an expensive noise machine. Start with outcomes: what does "resilient" actually mean for your business, and work backwards from there.
AI Agents in Modern SecOps and DevOps
Q: We’re seeing a growing focus on AI agents designed specifically for security and operational use cases. What’s changed in recent years that’s made this shift both possible and necessary?
If you haven't been living under a rock, you've encountered the surge in LLM and AI technologies first-hand. This is a technological shift on the same order of magnitude as the internet in the 90s or the smartphone in the 2000s. The ability for an AI agent to intelligently navigate a file structure, an architecture, or a web application, and not just understand it but decide how to exploit or defend it, is something that's very hard to ignore. What’s more important is that once you've seen it in action, you don’t want to go back. What's changed is the quality of reasoning these models can perform. They can reason, adapt, and act on context they've never seen before. This is great - it can free human experts from the intellectually unchallenging work such as reports, trawling through logs and repetitive queries so we can apply our curiosity and judgement to problems that actually require it. That's not a threat to security professionals; it's a significant upgrade.
Q: How do AI agents differ from earlier automation approaches in the way they support investigation, triage, and day-to-day decision-making?
Prior to AI, automation was essentially scripted behaviour - rules-based, rigid, and entirely dependent on what someone anticipated in advance. If the scenario wasn't in the playbook, the automation didn't know what to do. AI agents operate fundamentally differently: they can reason across novel situations, correlate signals they've never explicitly been trained to connect, and adapt their approach based on context. In a modern SOC, that's transformational. Instead of waiting for a rule to fire, an agent can observe anomalous behaviour, investigate across multiple data sources simultaneously, and surface a prioritised, contextualised finding. All of this in the time it would take a human analyst to open their first query window. The shift isn't just about speed, either. It's about coverage. AI doesn't get alert fatigue. It doesn't ignore the thousandth notification of the day. And research suggests that's a very real problem: around 60% of security teams have experienced incidents tied directly to alerts that were ignored, that actually turned out to be critical.
Trust, Autonomy, and Human Judgment
Q: Tools like Dojo AI are designed to assist teams during high-pressure moments. How should organisations think about trust when AI agents are influencing security and operational outcomes?
Trust is going to be the defining criteria for teams working with AI for the foreseeable future. LLMs are highly capable - tools like Sumo Logic's Mobot are excellent at accurately correlating and detecting unusual activity at scale. But how do you know you can believe it? The answer is transparency. Good AI tools show you exactly what they're doing, why they flagged something, and how they arrived at a conclusion. This is what allows teams to verify that the steps and the results actually make sense. When the AI says "I believe this isn't Medium severity, it's Critical, and here's my reasoning," you have everything you need to make an informed call. Black box AI that relies on obscure algorithms running invisibly in the background will not be trusted by most organisations, and rightfully so. Especially in regulated fintech environments, the audit trail matters as much as the outcome. If you can't explain a decision to a regulator, you've got a problem that no amount of accuracy will fix.
Q: There’s a lot of discussion around “human-in-the-loop” models - in practice, where do you see the right balance today between automation and human judgement?
I want to be clear on one point: human reasoning and intelligence is not going away. It is being re-deployed to higher-value parts of the operational process and that's a good thing. Automation is now in a far stronger position to handle low-intelligence, high-effort work: querying across large datasets, correlating information, generating dashboards and reports, and normalising alerts. These are things machines do better, faster, and at greater scale than humans. But all of that automation serves one purpose: helping us reach better outcomes. Who spun down the Kubernetes pod at 4am? Why did this person turn off the audit log? Machines can help surface the evidence rapidly, across terabytes of data but the judgement call remains human. I think of it as this: AI handles the investigation, humans make the decisions. Get that balance right and you've got a genuinely formidable operation.
Q: SecOps and DevOps teams often work with different priorities, data, and tooling. Can AI-driven platforms help bridge that gap, or do they risk reinforcing existing silos if not implemented carefully?
The goal should be to get all operational teams working from the same data. And we are at a moment in time where that is more achievable than it has ever been. Technology like Sumo Logic provides a centralised source of truth for the entire business - developers, SecOps, DevOps, even marketing. There are no formatting inconsistencies and a universal way to extract insights: Mobot. That reduction of barriers in the technology should, if implemented thoughtfully, reduce barriers between the teams themselves. Here's a real-world example: a Kubernetes node running at 90% CPU. DevOps investigates in an observability platform but can't pivot to logs easily so they spend ages running queries. Eventually someone spots logs that look like erroneous code and raises a ticket for the SOC. The SOC, a few hours later, identifies it as a malicious script deployed to the cluster. A high-severity incident is kicked off. Time between detection and response: hours. My question is simple. Why not bring those teams into a unified data landscape from the start, where Mobot can correlate across typically siloed observability and security data in minutes, without anyone needing to write a single query? The technology is there.
Q: How important is shared visibility and context when teams are responding to incidents at scale, and what role can AI play in enabling that?
The fact is that without visibility, you are vulnerable full stop. Attackers don't care that your engineers prefer a particular observability tool or that your security team swears by a specific SIEM. Attackers exploit your data irrespective of where it lives and what interface you happen to view it through. Shared visibility is non-negotiable. You need a data lake where you can store data for extended periods at a reasonable cost, and analyse it across multiple dimensions. At scale, AI becomes equally non-negotiable because the speed and breadth at which it can query and correlate across your data is simply beyond what any human team can match. The organisations getting this right are the ones treating visibility as infrastructure, not as a reporting exercise.
Common Pitfalls and Misconceptions
Q: What are some of the most common mistakes organisations make when introducing AI into security and observability workflows?
Organisations without a clear plan for AI will struggle. A directive like "your work should consist of 40% AI" is not a plan, it's a target that sounds strategic and means nothing in practice. There has to be an outcome-driven approach, with tangible, measurable ROI. How much time will it save your team when it comes to making sense of your data? How much faster can you resolve a P1 incident compared to before? These are the questions that matter. The second common mistake is treating AI as a standalone capability rather than integrating it into existing workflows. AI dropped on top of a broken process doesn't fix the process, it just automates the chaos. And the third: underestimating the change management piece. The technology is often the easy part; getting teams to trust it, use it consistently, and evolve their processes around it is where most implementations stall.
Q: Where do teams tend to overestimate AI’s capabilities today, and where do you think its value is still being underestimated?
AI has been a remarkable asset for operational teams, but limitations do still exist. Hallucinations remain a real risk in AI output, even in highly contextualised deployments where the model has access to your actual data. The risk is greatly reduced compared to general-purpose use, but it hasn't disappeared. That's why you still need people with genuine domain expertise to verify outputs and ensure the models are performing as intended. You can't fully replace the engineer or security professional who knows your landscape, your architecture, and your business inside and out. You shouldn’t want to do that either. Regarding underestimating AI, most organisations still aren't taking full advantage of AI's ability to connect signals across siloed datasets that no human team could realistically analyse in parallel. The value sitting unrealised there is significant.
Governance, Scale, and What Comes Next
Q: In regulated fintech environments, governance and explainability are critical. What should leaders be demanding from AI-powered SecOps tools to maintain accountability and trust?
Leaders should be demanding full transparency from their AI tools. The FCA, PRA, and regulators globally are increasingly clear that black-box AI is not acceptable in high-stakes financial environments. If your AI tool cannot show you why it made a decision, you cannot defend that decision to a regulator, an auditor, or a board. Beyond explainability, leaders should demand clear audit trails, human override capabilities at every critical decision point, and documented model governance. This includes how the model was trained, what data it uses, and how drift or degradation is detected over time. Think of it this way: the regulator isn't going to accept "the AI said so" as an answer and neither should you.
Q: Looking ahead, how do you see AI agents reshaping the relationship between SecOps and DevOps, and what should organisations be doing now to prepare for that future?
The lines between SecOps and DevOps are going to blur significantly and AI is the catalyst, in a good way as we discussed before. When both teams are working from the same data, querying it through the same interface, and receiving AI-generated insights that don't care about organisational boundaries, the distinction becomes less about who owns what and more about who has the right expertise to act. Research suggests that 83% of security leaders believe AI will handle over half of SOC workloads within three years. Whether or not that number holds, the direction is clear. What should organisations be doing now? Three things: invest in a unified data platform, build outcome-driven AI governance before you need it, and start upskilling your people. The teams that will thrive aren't the ones that adopted AI the fastest, they're the ones who understood how to apply it and use it fully.