AI vs. AI: From Alert Fatigue to Agentic Cybersecurity

AI is making both sides of cybersecurity faster. Attackers can generate and test phishing campaigns at scale, deploy malware that makes decisions on its own, and exploit the growing volume of code reaching production. Security teams, meanwhile, are using the same technology to investigate alerts, filter noise, and move toward autonomous response.

For Nir Soudry, Head of R&D at 7AI, that creates a clear imperative: defenders cannot meet AI-speed threats by continuing to add people to manual workflows. But giving agents more authority introduces a different question: when AI investigates and remediates security incidents, who remains accountable?

In this episode, Nir explains how organizations can introduce agentic security without expecting blind trust from day one. He walks through a gradual adoption model built on runbooks, organizational context, feedback, and human escalation; shares how 7AI reduces roughly 90% of alert noise; and describes a future in which security moves beyond reacting to alerts and starts preventing unsafe actions before they happen.

Key Topics Discussed

• (00:00) How AI is scaling phishing, enabling more autonomous attacks, and expanding the software attack surface
• (03:04) Why adding more people to security operations no longer scales, and why organizations still hesitate to adopt agents
• (05:17) Where accountability sits when AI investigates incidents and takes action
• (09:33) How to onboard an AI security system like a junior analyst, starting with low-risk work and earning trust over time
• (14:14) The runbooks, company context, and feedback loops required to make agentic security work in a real environment
• (17:35) What reducing roughly 90% of alert noise changes for security teams
• (19:30) The path from autonomous investigation to proactive security that blocks unsafe actions before they become incidents

Where to Find Nir Soudry

• LinkedIn: linkedin.com/in/nirsalon
• 7AI: 7ai.com

Transcript

Tell us about your career, your work at 7AI, and how your experience shaped your perspective on AI in security.

I lead R&D at 7AI, where we automate security investigations. We can take a security alert and automate the process of investigating it. I’ve been here for two years and was one of the company’s first employees.

Before 7AI, I worked at AWS and Alexa. Earlier in my career, I worked at Microsoft on products ranging from Windows 8 to Azure Security Center. My career has largely been built in high-stakes environments: systems serving huge numbers of customers where failure isn’t an option.

That experience taught me that on-call may be the most important part of building a system. It doesn’t matter what you create if it fails when customers need it. As organizations move faster and faster, however, it becomes increasingly difficult for people alone to maintain excellent on-call coverage and system performance. AI gives us a way to move quickly while also making systems more resilient in security and operations.

When companies face a growing number of security alerts, the traditional response is to hire more people. AI agents now offer another option. Why are many organizations still hesitant to embrace them?

In security, and in R&D more broadly, you tend to encounter two mindsets. Some people are trained primarily to minimize risk. That is understandable, especially in security, where reducing risk is the central responsibility and introducing innovation may not be.

Other leaders recognize that change is inevitable and that they need a different approach. They understand how the environment is evolving. Attackers are using more AI, which generates more alerts. At the same time, developers are using tools such as Claude Code and Cursor to produce far more code than they did only a few months ago.

More code means more complexity and, potentially, less reliable systems. The old response was to hire more people and place responsibility on them, expecting them to handle every edge case. People can do that, but the model doesn’t scale indefinitely.

Leaders looking ahead understand that the answer will be a combination of people and AI. AI can help create a more resilient system, while people move toward monitoring, auditing, setting direction, and making the judgment calls humans are best equipped to make. There is still hesitation, but the organizations that understand where the industry is heading know this is inevitable. It is better to begin learning now.

Accountability is one of the biggest differences between giving a task to a person and giving it to an AI agent. You can’t hold an agent accountable in the same way you hold a person accountable. How should organizations think about that?

Accountability still belongs to people, and it will continue to belong to people. Think about a self-driving taxi. The vehicle may drive itself, but people remain behind the scenes to monitor the system, tune it, and intervene in edge cases.

AI should work in a similar way. People define the policies and make sure the system behaves accordingly. At 7AI, we don’t expect customers to trust AI completely from day one. They should know that there is a person they can call when they need help.

Customers can use the AI while training their own teams to monitor, audit, and tune it. If they prefer, our people can help provide that oversight. The purpose of AI is to elevate the people using it and improve the organization’s security and operational posture. The human remains accountable and configures the system so that, whenever the AI is uncertain, the decision is escalated to someone who can exercise judgment.

AI is reshaping security on both the offensive and defensive sides. What new patterns are you seeing among attackers?

The most obvious example is the increase in SMS and email phishing. An attacker can create a campaign very quickly: generate a thousand variations of an email, send them to a thousand people, observe which versions get clicks, and then produce even more variations of the successful messages. AI makes phishing campaigns easier to create, personalize, test, and scale.

We are also beginning to see more autonomous attacks. Malware can make decisions on the infected machine without having to contact a command-and-control system for every step. It can inspect the systems around it, understand aspects of its environment, and decide what to do next.

There is another risk, particularly for SaaS companies: organizations are deploying much more code. Developers can pull in open-source code or use code written by AI without necessarily knowing whether it is secure. As more code reaches production, more vulnerabilities can be introduced, increasing the number of ways an attacker might get in.

When you describe autonomous malware, it sounds almost like a Trojan containing its own language model. How does that work?

I can’t discuss specific examples in depth, but the technology allows you to distill a model into a much smaller language model that can become part of a process. It doesn’t have to be a huge model. It can run on the compromised machine, interpret the local environment, and make decisions on its own.

Even relatively small models can now provide a meaningful degree of autonomy when they are running directly on someone’s system.

You’ve said teams should introduce AI gradually rather than trust it immediately. What stages should they go through?

The first thing to understand is that you are not simply buying a tool. You are beginning a partnership with another company to modernize your environment.

An AI system may work out of the box, but it won’t yet understand how your organization works. It is similar to onboarding a new employee. If you bring someone onto your team, give them no training, and let them operate exactly as they did at their previous company, they may still be productive. But their work won’t be tailored to your environment.

You would normally start a junior employee with a small responsibility. If they perform well, you give them something larger. If they struggle, you train and mentor them until they succeed. Teams should take the same approach with AI.

Start with a limited use case. Some customers begin with alerts their analysts don’t have time to investigate, such as identity alerts involving an anonymous login, a VPN, or an overnight access attempt. Sometimes those events are benign and sometimes they are malicious, but teams cannot wake someone in the middle of the night for every alert. Much of that activity is classified as noise, even though some of it may represent a real threat.

AI can begin by investigating those neglected alerts. Organizations that want to start even more cautiously can deploy it in development or staging environments.

During the first few days, the system needs to learn and be tuned to the environment. A good tool might identify that a particular alert is noisy only under certain conditions. For example, developers may repeatedly create storage buckets, make them public, and then delete them as part of testing. The system should recognize that pattern and ask whether those cases can be treated as benign.

The team can then define what should happen. Perhaps the AI should automatically close an alert when a known test pattern occurs. In another situation, the same behavior may always be malicious and require immediate action. If a bucket containing sensitive information becomes public, for example, the organization may instruct the AI to determine the context and automatically remove or rotate an exposed secret.

In practice, you are taking the runbooks you would give a junior analyst and making sure the AI can understand and follow them. The system also needs access to the right organizational knowledge. It may need to know which accounts belong to development, who is on the sales team, or which employees routinely work remotely and travel between locations. That context could come from identity, HR, cloud, and other internal systems.

This is an iterative process. The AI performs an investigation and presents its findings. If the team disagrees, it provides feedback. Ideally, the customer and vendor also meet regularly to review the results, correct mistakes, and tune the system together.

You aren’t just purchasing software; you are undertaking a modernization process. Trust in both the system and the people providing it matters. After a week or two, the system should become more accurate and resilient. Once both sides have reviewed its investigations and gained confidence, the organization can expand its scope and allow it to perform more sensitive remediation.

Eventually, people set the policies while the AI handles much of the repetitive investigative work, escalating only the cases that require human judgment.

What feedback should be given directly to the AI, and what feedback belongs with the software vendor?

In security, customers broadly fall into two groups. The first consists of sophisticated organizations, often large enterprises, with deep security expertise. They may have detection rules and runbooks developed over decades. They want the system to operate according to their own practices, incorporate their organizational context, and treat their internal knowledge as part of the tool.

Those organizations can give the AI their runbooks, monitor its performance, and tell it when an investigation was right or wrong. If they are committed to the process, they often have enough people to keep refining the system themselves.

Most companies, however, are not as opinionated or mature when it comes to security runbooks. Maintaining that expertise is difficult. People join and leave, taking institutional knowledge with them. Runbooks need to be updated, and traditional automations drift as the surrounding systems change. That is one reason security automation has struggled for so long: rigid rules become outdated.

For companies without a large security organization, the vendor should provide more of the expertise. At 7AI, we draw on what we have learned across many customer environments to recommend best practices and tune the system. If an alert is especially noisy, our team can examine it using a combination of AI, traditional machine learning, statistical analysis, and purpose-built scripts.

We may determine, for example, that an alert consistently originates in a development account and involves a bucket clearly marked for testing. We can then recommend tuning the detection, removing it, or creating a specific runbook for that scenario. Other customers may authorize the system to take action, such as automatically logging out a user when the activity appears suspicious.

A human still has to tune and monitor the system. In a mature organization, that may be someone on the customer’s team. In other organizations, more of that responsibility may sit with the vendor. AI can also help evaluate AI. For example, an LLM can act as a judge to monitor whether the system continues to perform correctly over time.

What measurable results do organizations see after implementing this approach?

We can ingest alerts from many sources, including on-premises systems, identity tools, and email security products. The system can cluster related alerts, recognize that they are part of the same case, investigate them together, and make a determination.

Typically, we can remove the noise from about 90% of alerts by determining that they are benign. What happens with the remaining 10% depends on the customer and the situation. A case may need to be escalated to a person for deeper investigation, or it may require mitigation or remediation, such as changing a configuration. In other cases, an employee may need additional training because they connected an unauthorized USB device or clicked a phishing link.

There is still work to do, and every customer is different. But reducing roughly 90% of the noise allows people to concentrate on the cases that actually require attention. When a customer is comfortable allowing the system to act automatically, AI can handle some of the remediation as well.

As language models improve, how do you expect security to evolve on both the attack and defense sides?

Over the next few years, I expect security operations to become fully autonomous on the reactive side. People will define their risk tolerance and policies, but every generated alert will be investigated and remediated automatically.

That would be a major improvement, but it would still leave us in a reactive model: an event occurs, an alert is generated, and the system investigates it as quickly as possible. At AI speed, even that may be too late. Within minutes, an attacker could already have obtained what they wanted.

Once the industry approaches a fully autonomous reactive system, the next opportunity will be proactive security. Today, antivirus software, phishing protection, and identity systems already block some suspicious activity. Yet thousands of alerts are still generated and sent to humans. In the near future, AI will resolve more of them automatically.

The real shift will come when defensive systems can block dangerous actions before they happen. Instead of investigating an event and then deciding how to respond, the investigation effectively occurs before the action is allowed.

Whether the event is a phishing email, a login attempt, or someone trying to expose a cloud storage bucket, the organization’s policies and knowledge should define what good behavior looks like in advance. Some malicious or unsafe actions could then be stopped before they generate an incident.

That future is still some distance away, and some areas will get there sooner than others. We are already relatively good at preventing conventional malware from being installed on managed machines. Cloud security and software vulnerabilities, however, still leave many openings for attackers.

The world’s overall security posture is not yet good enough. As long as defenders only react, whether the response comes from a person or an AI, the attacker still moves first. With AI accelerating the game, defenders will remain in pursuit until they can prevent more actions proactively.

Do you think generative AI will ultimately increase or decrease the number of security incidents? More generated code means more changes, which statistically creates more opportunities for something to break. But AI may also help detect problems before they reach production.

There is certainly a risk that the number of vulnerabilities and exposed secrets will grow as organizations produce more code. But AI is also becoming much better at scanning code intelligently and finding vulnerabilities that traditional static analysis may miss.

You can point an AI system at a codebase and ask it to examine the software in depth. Those capabilities are improving very quickly. That gives the industry a chance to protect itself even while producing code at a much faster rate.

Engineering teams have accumulated plenty of scars from deploying code and then watching it break something. AI could allow us to be more proactive on both sides: helping us create the code and helping us defend it before it is released. That gives me reason to be optimistic.

As defenses improve, will AI simply create new attack vectors through technologies such as synthetic video and voice?

That’s right. It is also what makes cybersecurity interesting and keeps people passionate about succeeding in this field.