Most organizations have no clear picture of the AI systems running inside their infrastructure, creating security blind spots that attackers can exploit. A new framework mapping the AI security landscape reveals that companies are discovering gaps in the same predictable order: first, they lose visibility into which AI services employees are using; second, they lack governance records for AI deployments; and third, they cannot identify exposed AI assets and misconfigurations before attackers find them.

What Are Organizations Missing in Their AI Security?

The problem starts with visibility. Your employees are already using artificial intelligence (AI) through sanctioned corporate tools, unsanctioned chatbots, and AI features embedded inside software-as-a-service (SaaS) applications your company already purchased. Browser agents that work on behalf of employees represent the newest and hardest-to-detect category, because they read web pages that nobody explicitly opened. Sensitive data flows into all of these systems, yet security teams can see almost none of it.

Beyond employee-facing tools, organizations have more AI assets than they realize. These include deployed models, API endpoints, machine learning notebooks, cloud services, and the digital identities and data attached to them. Some are publicly reachable on the internet. Some have permissions that nobody intended to grant. Without a systematic way to find these assets and check their configuration, companies remain unaware of which exposures actually matter.

The governance problem compounds the visibility challenge. Your board wants to know what AI is running, how risky it is, and what evidence you can show a regulator. The European Union AI Act is now enforcing, and ISO 42001 audits have started. Yet most organizations still rely on spreadsheets to track AI use cases, which cannot survive regulatory scrutiny. The real challenge: most of the AI your company runs was not built in-house. It arrived inside software you already bought, and vendor questionnaires from last year never asked about training data, model changes, or where the inference actually runs.

How to Build a Foundation for AI Security?

• Inventory AI Access and Usage: Start by discovering which AI services your employees are using, both sanctioned and unsanctioned. Identify public AI services, embedded SaaS AI features, and browser-level agents that operate outside traditional network visibility. Measure success by tracking the share of AI traffic you can attribute to a named user and a sanctioned service, and count how many AI services you discover that nobody had officially approved.
• Establish AI Governance and Assurance: Create a system of record for every AI use case in production, including who owns it, which controls it requires, and whether evidence of those controls is being collected. This governance layer should reach beyond security into reliability, privacy, and fairness, which is why it often sits with legal and compliance teams rather than the security operations center alone.
• Map AI Security Posture: Conduct a technical assessment of deployed AI assets and their configurations to identify which exposures actually matter. Trace each exposure from an AI asset to the data or system it puts at risk, identify the owner, and verify the fix. Measure success by tracking the count of publicly reachable AI endpoints and over-permissioned AI identities, trending downward over time.
• Verify Component and Supply Chain Integrity: Establish that every model, tool, and piece of data your AI systems depend on is what it claims to be and has not been modified. Model weights can carry executable code. Training and tuning data can be poisoned upstream. Embedding models, vector stores, orchestration frameworks, and tool descriptions that agents read are all components you did not write and mostly cannot see.

The order matters. Most organizations discover these gaps in sequence, starting with visibility into which AI services are in use, then moving to governance and assurance, then to technical posture management, and finally to supply chain security.

Why Does the Order of Discovery Matter?

The framework reveals that security teams tend to find problems in a predictable sequence because each layer builds on the previous one. You cannot govern what you cannot see. You cannot assess technical posture without knowing which assets exist. You cannot verify supply chain integrity without understanding which components your systems depend on.

For AI access and usage security, typical ownership falls to security operations teams, with human resources and legal advising on acceptable-use policies. The market for these tools remains mixed, with both specialist vendors and broader platform providers competing. After 90 days of implementation, organizations should be able to attribute most AI traffic to a named user and a sanctioned service, and they should have discovered AI services that nobody had formally approved.

For governance and assurance, ownership typically sits with legal, compliance, or a Chief AI Officer, with the Chief Information Security Officer advising. This category produces the system of record that regulators will ask to see. An approved use case still needs proof that its required controls are actually running. The governance layer coordinates security decisions but also reaches into reliability, privacy, and fairness, which is why it often sits outside the security function.

For AI security posture management, cloud security teams typically own the assessment. The market is converging into platforms, with major cloud providers folding AI-specific posture management into their broader cloud security offerings. Standalone vendors compete on depth and on visibility into environments that the major platforms do not yet see.

For component and supply chain security, product security or machine learning engineering teams typically own the verification, with application security advising. This category ensures that every part of your AI system is trustworthy and unmodified. A fraud or underwriting model retrained on data you never inspected presents the same risk as a large language model pulled from a public hub without provenance.

The challenge ahead is clear: organizations must move beyond reactive discovery and build systematic controls across all four layers. The vendors and platforms that can help teams follow this sequence, rather than jumping to the most visible problem, will likely become the foundation of enterprise AI security for years to come.