Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

CrowdStrike is introducing AI Discovery and Governance for CrowdStrike Falcon for IT, a new capability that helps organizations identify, assess, and govern AI technologies across enterprise environments. Enterprise IT infrastructure is the control plane for modern organizations. It determines how systems communicate, how identities authenticate, and how workloads execute across endpoints, servers, and clouds. This foundation supports the rapid implementation of AI across businesses.

TL;DR: In the age of frontier AI models, vulnerability discovery and exploit development are scaling faster than human defenders can manually respond. Security teams already face growing CVE volumes, shorter exploitation windows, and manual workflows for researching vulnerabilities, creating protections, validating them, and preparing them for deployment. As attackers weaponize vulnerabilities faster than organizations can patch them, time-to-protect is becoming a critical security metric.

Most AI deployments run without formal controls over what data they can reach, what decisions they make, or how they behave in production, yet regulators now require answers to all three. AI governance tools address these risks across three distinct layers: model governance, data access governance, and observability. Most enterprises need coverage across more than one layer. AI governance has shifted from a voluntary best practice into a formal compliance requirement.

At the World Economic Forum cyber meeting in Geneva recently, I had an interesting conversation with Vinh Nguyen, who is a strategic security advisor and Senior Fellow for AI at CFR. I wanted to know from him how he sees runtime governance in agentic AI working out practically and what approaches actually work. One of the challenges he mentioned was that yes, we need runtime governance to provide continuous and real time assurance that agents are doing what they are supposed to be doing.

A security team running agents in production can already list the ways those agents get attacked: prompt injection, memory poisoning, tool abuse, model tampering, agent-to-agent coercion. The list is not the problem. The problem is that a security architect can recite all five and still not know which ones their detection stack will catch, because the way the field catalogs these attacks says nothing about whether the attack is catchable.

The early stages of an AI agent attack are silent. The poisoning, the hijacked intent, the reconnaissance: none of it executes, so none of it produces a runtime signal, and the kill-chain instinct every security team runs on says exactly the wrong thing here: break the earliest link. There is no early link to break. You cannot detect a stage that emits nothing.

A compromised agent doesn’t make a single call it isn’t allowed to make. It queries a table it’s authorized to read, calls a tool it’s authorized to use, sends to a domain that’s on the allowlist. Every call is legal. The attack is in the values it passes, and your tool-call log records all of it as a clean day’s work. A tool call has two layers. Almost every tool you run reads the first one: the call itself: which tool, in what order, at what rate.