The Framework That Defined Cybersecurity Doesn’t Work for AI. Here’s What Does.

I have spent a lot of time thinking about frameworks.

Not because frameworks are inherently interesting - they are not. But because the right framework at the right moment changes how an entire industry thinks about a problem. And the wrong framework - or the right framework applied to the wrong problem - produces a false sense of coverage that is more dangerous than no framework at all.

In cybersecurity, we had the right framework for a long time. The Cyber Defense Matrix, created by Sounil Yu, gave the industry something it desperately needed: a shared analytical structure for understanding what you need to protect, how you need to protect it, and where your gaps are.

Devices, Applications, Networks, Data, Users down the rows. Identify, Protect, Detect, Respond, Recover across the columns. Every vendor could point to their cell. Every CISO could map their coverage. Every board conversation could be structured around demonstrable completeness rather than vague assurance.

I used it. Everyone I know in security used it. It worked.

And then AI agents arrived - and the framework stopped working. Not because it was wrong. Because the problem changed in a way the framework was not designed for.

What the Matrix Got Right

Before I explain why the matrix does not work for AI, let’s go over what it got right - because the discipline behind it is precisely what the AI security market is currently missing.

The matrix worked because it forced two simultaneous conversations. First: what assets do I need to protect? Second: what capabilities do I have across the full spectrum of how I protect them - before an incident, during an incident, and after one?

It turned from “do we have enough security?” - a question with no good answer - into “which cells are covered and which are not?” - a question that could be answered with reasonable precision.

That discipline is almost absent from how enterprises think about AI security today. Most organizations are doing one of two things. They are assuming their existing stack covers AI because it covers the underlying infrastructure - the same devices, the same applications, the same network. Or they are buying point solutions that claim to address “AI security” without being specific about what they actually cover or where they fit in the landscape.

Neither approach produces real coverage. Neither produces clarity. And the gap accumulates exposure in real time because the agents are already running.

The matrix gave us the right analytical instinct. The question is whether we can apply that instinct to a class of actor it was never designed for.

Someone Tried to Replicate It for AI. It didn’t go as planned.

I have looked at these frameworks carefully - because getting this right matters, and I wanted to understand where others have landed.

They run into the same wall for a consistent reason.

Every attempt I have seen, including this one, treats AI as a new asset class to be added to the existing structure. A new row. A new column. An extension of what the matrix already does - applied to models, applied to agents, applied to AI infrastructure.

That approach does not fully work because it starts from an incomplete assumption. It assumes AI security is a new thing to protect using existing analytical categories. It is not only that. AI security is also a new way that every existing category gets implicated simultaneously - by a class of actor the original matrix was not designed to represent.

Adding a row names the problem. It does not, on its own, govern it.

The Actual Problem: AI Security Is the Entire Spectrum (say it louder for the people in the back)

Here is the insight I keep coming back to - the one that I think the failed AI matrix attempts consistently miss.

AI security is not another pillar in the Cyber Defense Matrix. It is the entire spectrum.

A single enterprise AI agent - built by one person in Finance on a Tuesday afternoon, connected to your ERP and your reporting system and your communication tools - simultaneously implicates every row of the matrix in a single interaction.

It runs on devices - but it is not a device. Endpoint protection governs the device it runs on. It does not govern what the agent decides to do while it is running there.

It uses applications - but it does not act like one. It acts more like a user. Application security governs the software. It does not govern the autonomous decisions the agent makes while using that software, or whether those decisions match what the agent was built to do.

It generates network traffic - but network controls cannot distinguish a legitimate agent API call from data being exfiltrated through an authorized channel. The packets look identical.

It accesses and generates data - but DLP was built for data leaving through known, classifiable channels. An agent processing sensitive information through a legitimate tool call does not trigger a DLP rule. The channel is authorized. The actor is ungoverned.

It operates under user identity - but it is not a user. IAM governs what a user is permitted to do. It does not govern what the agent built by that user actually does with those permissions - or detect when the agent starts doing something the user never intended.

Every single row. Every single column. One agent. One interaction.

You cannot govern this by assigning it to a cell. The analytical unit of the matrix - a specific asset class managed by a specific capability - breaks down the moment you try to apply it to an actor that is simultaneously all asset classes at once.

No Single Company Can Cover All of It

I want to say something here that most vendors in this space will not say, because it is not in their commercial interest to say it.

No single company - including aizome - can cover the full AI security spectrum.

The scope of what it would take to provide complete AI security across every row and every column of the matrix, applied to every type of AI agent an enterprise now deploys, is genuinely too large for any one platform. A vendor that claims to provide complete AI security is either misrepresenting their capabilities or has not thought carefully enough about the scope of the problem.

Think about what complete coverage would actually require. Comprehensive DLP across every layer of the stack - discovery, classification, real-time protection, and response - applied to AI agent interactions. Network monitoring capable of distinguishing legitimate agent API calls from exfiltration events at the semantic level, not just the packet level. Endpoint protection that governs not just the device an agent runs on but the decisions the agent makes while running. Application security that extends to autonomous agent behavior within those applications. And on top of all of that: identity governance, intent enforcement, and behavioral monitoring for the class of actor that cuts across all of those layers simultaneously.

That is not one product. That is a stack. The same way traditional cybersecurity is a stack - IAM plus EDR plus DLP plus CASB plus SIEM plus a dozen other tools working in concert - AI security will resolve into a stack of specialized capabilities that work together.

The enterprises that govern AI security well will be the ones that build that stack thoughtfully, understanding what each layer covers, where the gaps are, and how the pieces interact. The ones that assume one vendor covers everything will discover the gaps the hard way.

But the Starting Point Is Not Arbitrary

Acknowledging that no single vendor covers the full spectrum does not mean all starting points are equal. They are not.

When I think about which cell of the matrix is most critical - which capability, if absent, makes every other capability less effective - the answer is consistent across every row.

It is identity.

Not because identity is the most visible gap. Not because it is the most obvious product category. Because identity is the prerequisite that makes every other capability in the matrix functional for AI agents.

Here is the argument precisely.

On the Identify side of the matrix: You cannot run a critical asset inventory for AI agents without knowing what agents exist and who owns them. You cannot establish identity attributes for a class of actor with no governed identity. You cannot assess known weaknesses in agents that have no baseline behavior. Identity is the prerequisite for everything the Identify column requires.

On the Protect side: You cannot apply structural awareness to an actor with no defined structure. You cannot enforce deterministic controls on an agent with no governed scope. Every protection capability in the matrix requires a defined, governed identity to attach to.

On the Detect side: You cannot identify unexpected behavioral changes in an actor with no established baseline. You cannot assess the meaning of changes in behavior you have never characterized. You cannot map impacted assets to an agent incident without attribution. The Detect column requires behavioral baselines that can only exist if identity has been established first.

On the Respond and Recover side: You cannot respond to an incident that has no attributable actor. You cannot recover accountability if no one knows who authorized the agent that caused the problem. Response and recovery require the audit trail that governed identity makes possible.

Identity is not the most important row in the matrix. It is the foundational layer that makes every row functional - for the specific class of actor the matrix was not built to govern.

Without it, you can build a sophisticated security stack across every cell and still have no effective coverage for the AI agents operating across all of them simultaneously.

The Two Sides of the Matrix - And Which One to Prioritize First

Even within the identity layer, there is a sequencing question that I think enterprises consistently get wrong.

The matrix has two broad sides. The left side - Identify and Protect - is the posture management side. It is about understanding what you have, establishing structure, and building the controls that prevent incidents before they happen. At Axonius, this is largely where we played: asset intelligence, structural awareness, the ability to answer “what do I have and what does it look like?”

The right side - Detect, Respond, Recover - is the real-time operational side. EDRs, SIEMs, incident response platforms. The tools that tell you when something is happening, help you stop it, and help you recover from it.

Both sides matter. But they are not equally urgent in the same order for every problem.

For AI agent security, what we actually see is most organizations starting on the left side - chasing visibility - and postponing the real-time side, DLP and browser extensions aside. That instinct is right. But it usually stops short: the real-time tools that do get deployed still mostly lean on known patterns, and known patterns are a weak defense against an actor that improvises - like running airport security off last year’s banned list. The problem is that detection without posture is noise. You cannot detect deviation in an actor with no established baseline. You cannot respond to an incident with no attribution. You cannot recover accountability with no audit trail.

The posture management side - identity, inventory, behavioral baseline, scope definition - has to come first. Not because detection is less important. Because detection without the posture foundation produces alerts that cannot be acted on, incidents that cannot be attributed, and responses that cannot be structured.

Establish the identity layer. Build the behavioral baseline. Define the scope. Then detection becomes meaningful. Then response becomes actionable. Then recovery becomes accountable.

Posture first. Real-time second. In that order. For that class of actor.

A Tool for Assessing Your Coverage - And Your Vendors

One of the things the Cyber Defense Matrix did best was give CISOs a tool for evaluating vendors. Which cell does this vendor occupy? Which cells do I still need to fill? What does complete coverage look like?

The AI security market needs that tool. It does not have it yet. What it has instead is a collection of vendors making broad claims about AI security coverage without a shared framework for evaluating those claims.

Here is a starting framework - not a complete matrix, but a set of questions that apply the matrix discipline to AI agents specifically.

Identify: Can you inventory every AI agent in your environment - registered and shadow - mapped to its owner, the systems it connects to, its behavioral baseline, and its risk profile? If you cannot answer this question, the Identify column has no foundation for AI agents regardless of what else you have deployed.

Protect: Does every agent in your environment have a governed identity scoped to its actual declared purpose - not just the permissions of the person who built it? Are actions validated against that declared purpose before execution? If not, the Protect column is governing the wrong unit of analysis.

Detect: Do you have behavioral baselines per agent that allow you to detect deviation from declared intent - not just from policy, but from the specific purpose the agent was built to serve? Does that baseline include what sensitive data the agent typically touches, so unusual data exposure or leakage shows up as deviation too - not just unusual actions? Can you detect drift before it produces a visible incident? If not, the Detect column is reactive rather than preventive for AI agent risk.

Respond: When an agent goes out of bounds - behaviorally, in data volume, in system reach- can you act before the action executes? Or are you responding after the fact to damage that has already been done? Response speed for AI agent incidents is measured in seconds, not hours or days.

Recover: When something goes wrong, do you have a complete, attributable audit trail from identity to tool call to action to outcome - structured for SIEM ingestion and ready for regulatory review? Without full attribution, recovery is incomplete regardless of technical remediation.

The Same Discipline, Applied to What the Agent Touches

The five questions above apply the matrix discipline down the columns - Identify, Protect, Detect, Respond, Recover. The same discipline applies down the rows - the asset classes an agent actually touches. Both axes matter, and most vendors, including us, should be able to answer both.

Devices: Does the solution cover every surface an agent actually runs from - not just the managed endpoint, but the cloud instances and SaaS applications an agent operates inside with no device to install on? If coverage stops at the endpoint, most of where agents live goes unwatched.

Applications: Is it protecting the enterprise applications an agent can reach - not just from traditional exploits, but from the AI-specific risk introduced through MCP servers and skills? And does it cover every agent provider actually in use - Claude, Copilot, OpenAI, and the rest - or only the one it was built around?

Network: Is traffic protected no matter how the agent reaches it - through the application itself, a browser, or mobile? And past the transport layer, does it understand the protocols agents actually communicate through - A2A, MCP, skills - not just the packets those protocols produce?

Data: Does it protect data consistently across local and SaaS environments? Does it account for the human’s intent when evaluating what an agent does with that data - not just which data it touched? And does it catch accidental leakage out to the open internet, not only deliberate exfiltration?

Identity: This is where the argument in this piece started, and it’s where aizome’s coverage runs deepest - every agent, every provider, mapped to a governed, accountable owner. If the first four questions expose gaps, this is the one row nothing else on this list works without.

Ask these questions - down both axes - of every vendor in your AI security stack, including aizome. If a vendor cannot answer for the specific class of actor you are trying to govern, you know which cells they occupy and which ones they do not.

That is the matrix discipline applied to AI. Not a new row. A new lens on the same analytical structure - applied to an actor that cuts across every row simultaneously.

What This Means for How You Build Your Stack

If you accept the argument I have made here - that AI security is the entire spectrum, that no single vendor covers it, that identity is the prerequisite that makes every other layer functional, and that posture management comes before real-time detection - then the practical implication is straightforward.

Build the stack the same way you built your traditional security stack. With clarity about what each layer covers. With honesty about where the gaps are. With a sequencing that reflects the dependencies between layers rather than the marketing claims of individual vendors.

Start with identity. Not because aizome builds identity governance for AI agents - though we do. Because without it, the detection tools have nothing to detect against. The response tools have no attribution to work with. The recovery tools have no audit trail to reconstruct from.

Then build outward from that foundation - network monitoring that understands agent traffic, application security that extends to agent behavior, data protection that covers agent tool calls, endpoint controls that govern agent decisions.

No single vendor covers all of it. The matrix discipline tells you which cells you have covered and which ones you do not. And the specific cell that has to be covered first - the prerequisite for every other cell - is the identity of the actor that cuts across all of them.

The Cyber Defense Matrix was right. The actors have changed.

Build the new stack with the same discipline that made the original one work.

A Note on What aizome Does

I want to close with the same intellectual honesty I opened with.

aizome governs the identity and intent layer for enterprise AI agents. We discover every agent in your environment - registered and shadow. We assign governed hybrid identity to every agent interaction. We enforce intent continuously - measuring every action against declared purpose before execution. We detect behavioral drift in real time. We log every outcome in a tamper-evident audit trail from identity to tool call to result.

That covers a significant portion of the Identify and Protect columns, and provides the foundation that makes the Detect and Respond columns functional for AI agents.

It does not cover everything. It was not designed to. It was designed to be the layer that makes everything else governable - the prerequisite that the rest of your AI security stack is built on.

If you are building your AI security program from the matrix up - and I think that is the right way to build it - start with the question that every other question depends on.

Do you know who your agents are? What were they built to do? And whether they are still doing it?

If the answer is no - start there. Everything else in the matrix follows from that answer.

Roee Salomon is CTO and Co-Founder of aizome, the Enterprise AI Agent Control Platform. aizome governs the identity, intent, and accountability layer for enterprise AI agents. aizome.ai