The IT Nerd

As we’re all learning, in both frontier AI models and enterprise tools now in use, AI can get it wrong. 

Most security teams don’t discover that an AI tool was wrong during testing. They find out either when an alert storm starts, their analysts stop trusting the tool, or a real threat slips through undetected.

Teams are asking how they can validate outputs in live environments before they cost time, money or a breach. It’s not yet a publicly discussed issue, but it’s one of the most important ones a security team has to resolve.

Yasir Zahid, Cybersecurity Leader and Founding Member with Secure.com, has published the helpful guidelines in his analysis: “How Do You Validate the Outputs of AI-Native Security Tools in a Live Environment?“

Among key takeaways:

• AI outputs in live environments can be 45-50% less accurate than vendor tests suggest.
• Shadow mode testing, monthly Red Team replays, and metric drift tracking are the three most practical tools for live environment validation.
• If the AI cannot explain why it made a call, you can’t verify whether it was right.
• Analyst override rates are the most honest feedback signal you have. If analysts are regularly rejecting AI recommendations, that tells you what needs to change.
• Validation is ongoing, not a one-time setup task. Model behavior drifts as environments change, and that drift needs to be checked monthly.

You can read more here: How Do You Validate the Outputs of AI-Native Security Tools in a Live Environment? – Secure Blog

With organizations adopting AI-powered SOCs, much of the attention focuses on reducing false positives. False negatives where AI falsely clears an attack or its early phases is far less discussed, but far more problematic.

Yasir Zahid, Cybersecurity Leader and Product Builder with Dubai-based Secure.com, has just published “When an AI SOC Gets It Wrong: False Negatives, Risk, and What Comes Next.“

Yasir’s detailed analysis recognizes that AI SOCs miss real threats more often than SOC teams and their organizations expect, and lays out the costs of false negatives to the average organization.

• AI detection tools lose ~between 45 and 50 percent of their tested accuracy when deployed in real environments because of differences in data, infrastructure and dynamic, evolving threats.
• Up to 40 percent of alerts in a standard SOC go completely uninvestigated – and that slow detection is a strong potential driver for escalating estimates of the cost of a data breach.
• An effective SOC is a  well-governed one that logs what it missed, flags gaps, routes uncertain signals to human review, and escalates ambiguous as well as high-risk cases to supervising humans.

You can read more here: What Happens When an AI SOC Misses a Threat

Dubai-based Secure.com has just issued “21 Holes in 3 Production Stacks: What AI Pentesting Actually Finds in 2026,” new research proving just how far AI-driven pentesting has moved from theory to operational risk. In a single weekend, an automated pipeline with no human in the loop uncovered 21 vulnerabilities across three live production stacks, including 7 critical issues tied largely to basic security hygiene failures.

Secure.com researchers pointed an AI-driven pentesting pipeline at three well-known production systems and found

• Multi-tenant e-commerce marketplace: Frontend Runtime Config Leaked on Every Page Load; Unauthenticated Scheduler & Admin Endpoints; Unauthenticated Notification Injection
• Generative AI imaging platform: Cross-Origin Session Theft Across All Four Backend APIs; Admin Dashboard Publicly Reachable
• Popular consumer password manager: Full Production Environment Exposed in Public JavaScript Bundle

This materially changes the economics of both attack and defense. What until now took skilled human testers and significant budget can be executed continuously for roughly $18 per hour, raising questions about whether periodic pentesting models are still viable.

21 Holes in 3 Production Stacks – What AI Pentesting Actually Finds in 2026: Three clients. Three very different architectures. One weekend of machine time: https://www.secure.com/resources/holes-production-stacks

Dubai-based Secure.com has published a concise analysis of both sides of the coin in  “The CISO’s Guide: When AI Helps vs. Hurts Security.”

With research revealing that 76% of CISOs reporting that they expect a material cyberattack in the next 12 months, most report that their organizations are already using AI in some form.

The Guide examines key issues including:

• Where AI Actually Delivers for the SOC:  AI doesn’t think, it predicts, and every model’s no better than the data it was trained on.
•  Where and How AI Can Quietly Hurt The Organization
• The Four Questions to Ask Before Deploying Any AI Security Tool: Every AI system makes mistakes. The question is whether mistakes are recoverable.
• Building a Security Program Where AI and Humans Work Together: Gall’s Law applies.
• Shadow AI Prevention Measures: Shadow AI is a growing internal risk that can expose sensitive data without the user realizing it.
• Metrics to measure deployment success.

The question is no longer “should we use it?” It’s “are we using it in the right places?” The CISO’s Guide delivers a clear, honest answer to that question, and full content is below.

You can read the analysis here: The CISO’s Guide: When AI Helps vs. Hurts Security

Dubai-based Secure.com has just published – “Designing Security Workflows Humans Don’t Hate” based on input from organizations across more than 30 countries. 

CEO Uzair Gadit advocates for human-first security workflows, designed around how people actually work, not how tools were built. The human-first approach surfaces what is relevant, removes friction from the right actions, and puts human judgment where it is needed most, instead of everywhere.

He said: “Most security workflows treat people like machines. They expect analysts to process hundreds of alerts, jump between tools, and make fast decisions under pressure all day, every day. Over 70% of SOC professionals say they have considered quitting due to stress and unmanageable alert volumes. That isn’t  a sign of weak teams. It’s a sign of broken workflows.”

The brief analysis examines:

• Why most security workflows drive people away, amplifying rather than reducing risk;
• Elements of human-first security design; and
• Human-in-the-loop versus automation – where it works, where it doesn’t.

You can read the analysis here: https://www.secure.com/blog/human-centered-security-workflows

Today, Uzair Gadit, Founder & CEO of Dubai-based Secure.com ( https://www.secure.com/ ), published new analysis: “Open Source Dependency Risk Management,” which begins with the reminder that most apps today run on open source code, and 84% of those codebases carry at least one known security vulnerability.

He discusses why open source dependency risk management is important to SMBs, MSSPs and enterprises alike, noting that:

• Scale makes manual tracking impossible,
• Attackers know developers trust open source, 
• Regulatory pressure is rising,
• Unfixed vulnerabilities compound over time, and
• License misuse can cost millions. 

In addition to examining some common risks of O/S dependencies, such as security vulnerabilities,  malware injections, transitive dependencies and unmaintained code, the analysis offers specific risk reduction recommendations.

These include enforcing a quality gate on coding, and effective tracking to measure open dependency risks over time, as well as their severity and the organization’s resolution speed.

The recommendations are timely, given that Sam Sabin of Axios reported today that volunteers “who keep open-source software running and secure are being flooded with reports from an unlikely source: autonomous AI agents… The vast majority of this software is maintained by volunteers who were already struggling to keep up with the deluge of reports about security flaws. Now, maintainers tell Axios their inboxes are being inundated by a wave of AI-written reports that lack specific details and legitimate errors.“

Open Source Dependency Risk Management: Most apps today run on open source code — and 84% of those codebases carry at least one known security vulnerability:  https://www.secure.com/blog/open-source-dependency-risk-management

Uzair Gadit, Founder & CEO of Dubai-based Secure.com, has just published “Cloud Misconfiguration vs Vulnerability: What’s the Difference? Most cloud breaches aren’t hacks — they’re open doors you forgot to close.“.

The brief post equates mis-configurations. versus vulnerabilities as analogous to open doors versus broken locks.

 “Most IT teams treat every cloud security issue the same way. A new CVE drops? Patch it. But what about the S3 bucket someone left public last Tuesday? That doesn’t show up in a CVE database. It shows up in a breach report.

“Cloud environments are not static. Every new service spun up, every new developer onboarded, every shortcut taken under deadline pressure is a chance for a setting to go wrong. The confusion between misconfigurations and vulnerabilities is costing companies millions — not because they don’t care, but because they’re solving the wrong problem,” Uzair said.

He notes that most security budgets are built around patch management which makes sense on prem, but in the cloud is the wrong playbook.

Uzair offers specific vendor neutral recommendations and key takeaways:

• A leading analyst organization estimates 99% of cloud security failures come from misconfigurations — not software bugs.
• Misconfigurations are easier to exploit. No hacking skills required. A Google search can find an exposed S3 bucket.
• Shadow IT and cloud sprawl cause “configuration drift”, i.e. settings that slowly become unsafe as environments grow.
• The fix is a mix of automated audits (CSPM tools), least-privilege access, and shift-left security in your CI/CD pipeline.

Cloud Misconfiguration vs Vulnerability: What’s the Difference? Most cloud breaches aren’t hacks — they’re open doors you forgot to close: https://www.secure.com/blog/cloud-misconfiguration-vs-vulnerability