Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Anyone who knows me knows I’m passionate about mindfulness. Because I genuinely believe it makes us better humans. But also, because I have one of those brains that desperately needs it. I’m easily distracted and I start new ideas before finishing old ones. My attention can scatter in a hundred directions. I wrote before how I clicked on a phishing test because I was multitasking and running on autopilot. And that moment really changed the direction of my career and my research.

As I was writing my latest book, How AI and Quantum Impact Cyber Threats and Defenses, I was hit by how many theoretical and real attacks there are involving AI. There are attacks committed by AI and attacks committed agsinst AI, and I’m not sure which category is bigger.

AI security tools are no longer just defensive layers. They are high value targets being studied, fingerprinted, and bypassed much like traditional endpoint detection and response (EDR) platforms and antivirus solutions were in their early days. The speed and scale at which these tools are being deployed makes reactive defense increasingly unsustainable.

Synthetic data has been fine for testing software for decades. Traditional apps follow rules. You check inputs, check outputs, file a bug when something breaks. AI is different. AI gets deployed into the situations where the rules aren’t clear and context is everything. The edge cases aren’t exceptions. They’re the whole point. That changes what your test data needs to look like.

Explore the risks and benefits of the Dark Web and learn why Dark Web monitoring is essential for identifying threats, preventing data breaches and strengthening cybersecurity.

Modern software development relies on open-source components to accelerate innovation. This efficiency, however, introduces significant risk. Your application’s security is now tied to a vast and complex supply chain of code you did not write. The persistent software supply chain challenge is that this external code is a primary source of critical vulnerabilities and a hard.

When your SOC alerts on “suspicious AI activity” in a production trading system, your response team faces a question that didn’t exist two years ago: can you explain to regulators exactly which function processed the malicious prompt, which internal tool it called, and how customer data ended up leaving your environment?

It’s 2:47 AM and your SOC dashboard lights up. Six alerts fire across three hours from a single Kubernetes cluster: an outbound HTTP fetch to an unfamiliar domain, a tool invocation inside a customer support agent, an API call to an internal service the agent has never contacted, a service account token read, a file write to a model artifact directory, and an outbound data transfer that looks like normal API usage.

You’re forty-five minutes into a vendor demo for AI workload security. The dashboard looks polished—posture scores, misconfiguration findings, vulnerability counts, all tagged with an “AI workload” label that wasn’t there last quarter. You ask the obvious question: “Show me how this detects a prompt injection attack on our production agent.” Long pause. The SE pulls up a generic process anomaly rule.

You’ve been securing Kubernetes workloads for years. Your CSPM is running, your CNAPP is configured, your team knows how to triage container alerts. Then an AI agent lands in your cluster — maybe from the data science team, maybe from a vendor integration, maybe from a tool you didn’t even know was running. Within a week, it’s making API calls nobody planned, accessing data stores that aren’t in the architecture diagram, and executing code it generated itself.