AI Security Isn’t One Thing — It’s a Stack

1. Model and AI Pipeline Security

The first area is what I’d call model and AI pipeline security.

This is where a lot of the early focus has been — making sure the model itself, the data feeding it, and the overall pipeline are secure before anything ever gets deployed.

These solutions are looking for things like:

·      Vulnerable or unsafe models

·      Poisoned or manipulated training data

·      Weaknesses in RAG pipelines

·      Supply chain risks in models and dependencies

Some of them also do automated red teaming — basically stress testing the model to see how it behaves under attack before it goes into production.

This makes a lot of sense, especially for companies that are building their own models or heavily customizing AI applications.

The challenge is that once the system is live — especially when you start introducing agents that can take actions — this layer doesn’t really help with what the AI is actually doing in real time.

It’s more about making sure you’re starting from a good place, not necessarily controlling behavior once things are running.

Vendors in this space include companies like Protect AI, HiddenLayer, and Noma Security — although most of them are already expanding beyond just model and pipeline security into runtime and broader AI security capabilities.

Cisco also plays here to some extent with model validation and red teaming, but like others, it’s extending across multiple layers.

Where this tends to fit best is with organizations that:

·      Are building or fine-tuning models

·      Have internal AI platforms

·      Care about model risk and supply chain security

It’s a foundational layer — but on its own, it’s not enough once you start moving into more autonomous, agent-driven workflows.

2. Runtime Guardrails

The next layer — and probably where most of the activity is right now — is what I’d call runtime guardrails.

This is focused on what’s happening while the AI system is actually running.

Things like:

·      What prompts are coming in

·      How the model is responding

·      What data is being pulled in through RAG

·      What tools the agent is trying to use

This is where a lot of the real risk starts to show up — prompt injection, data leakage, agents doing things they shouldn’t, or being manipulated into taking actions outside their intended scope.

So these solutions sit in-line with the AI application and try to inspect and control behavior in real time — across prompts, responses, and increasingly tool use and agent actions.

This is where you see vendors like Cisco AI Defense, Lakera, Prompt Security, and others.

Cisco is an interesting example here because it’s not just a runtime guardrail solution.

While a lot of its strength is in protecting interactions — prompts, responses, and model behavior — it’s also extending into things like model validation, AI discovery, and overall visibility into how AI is being used.

So instead of fitting neatly into one category, it’s starting to look more like a platform that spans multiple layers of the AI lifecycle.

Cisco has also been leaning into agent-specific protection with things like DefenseClaw, an open source layer designed to sit directly in the agent loop and apply controls around prompt handling, tool invocation, and agent behavior.

That’s interesting because it shows where things are going — not just protecting models, but actually inserting controls into the agent execution loop itself.

But even with all that, this layer still has limitations.

A lot of what it’s doing is still probabilistic. You’re trying to detect intent from prompts, or determine whether something “looks” malicious. That’s hard to get perfect.

And more importantly, if something slips through and eventually something will, this layer doesn’t actually control what happens at execution.

So, while runtime guardrails are probably the most important layer right now, they’re still not a complete solution on their own.

3. Agent Governance and Intent Control

The next layer is where things start to get a little more interesting and honestly, a bit confusing at first. This is what I’d call agent governance or intent control.

At a high level, the idea here is simple:

It’s not just about what the model is saying, it’s about what the agent is actually trying to do.

As agents become more autonomous, they’re no longer just generating responses. They’re taking actions , calling APIs, interacting with systems, triggering workflows.

And the risk isn’t always that something is malicious. A lot of times it’s just the agent doing something it shouldn’t or doing the right thing in the wrong way.

That’s where this layer comes in.

Instead of looking at prompts and responses, these solutions try to understand:

·      What the agent’s goal is

·      What actions it’s planning to take

·      And whether those actions align with policy

Vendors like ArmorIQ and Zenity are starting to focus here — although even in this space, many are expanding beyond just governance into broader agent security and runtime protection.

The easiest way to think about it is this:

Runtime guardrails are trying to infer intent from prompts and behavior. This layer is trying to validate intent before execution.

That’s a big shift.

In theory, this is powerful because you can stop bad or misaligned actions before they ever happen.

But it’s also where things get tricky.

Defining intent and policy at that level isn’t easy. You must understand what the agent is supposed to do, what it’s allowed to do, and how much autonomy it has.

And in a lot of environments, that’s still evolving.

4. Execution and Endpoint Control

The final layer is the one that, at least to me, feels the most concrete.

This is execution control at the endpoint or system level.

Up until this point, everything we’ve talked about is trying to understand or influence what the AI is doing, its reasoning, its intent, its behavior. This layer is different.

It doesn’t care why something is happening. It just asks a much simpler question:

Should this be allowed to run or not?

As agents start interacting with real environments, they’re doing things like:

·      Running scripts

·      Calling APIs

·      Installing packages

·      Accessing files

·      Triggering workflows

At some point, all of that turns into actual execution. And that’s where this layer steps in.

Vendors like Koi (PAN announced to acquire) are focused here, bringing visibility and control to what actually executes on the system, especially around things like extensions, packages, and agent-driven interactions with the local environment.

It’s less about understanding intent and more about controlling what ultimately gets to run.

What I like about this layer is that it’s deterministic. Something either runs, or it doesn’t.

But like everything else, it has tradeoffs. By the time you’re at execution, a lot has already happened.

So, while this layer can stop the final action, it doesn’t necessarily prevent everything leading up to it. Still, as agents become more capable, it’s hard to see how you don’t have some level of control here.

So What Actually Makes Sense?

After looking at all of this, the obvious question becomes:

What should a customer actually do?

And this is where it starts to get a bit messy because there’s a lot of overlap across these layers.

Each layer is solving a different problem. And more importantly none of them are complete on their own.  You could have strong runtime guardrails, but if something slips through, you still need control at execution.

You could have tight execution control, but that doesn’t help you understand whether the agent is behaving correctly upstream. It’s very similar to what we’ve seen in other areas of security.

You don’t rely on just one control point — you layer them.

At the same time, the market is already starting to show a familiar pattern.

Some vendors are going deep in one area. Others are trying to expand across multiple layers and build broader platforms.  It’s the classic tradeoff.

One thing that cuts across all of this and becomes even more important with agents is identity.

At the end of the day, agents are acting with permissions.

What they can access, what they can call, and what they’re allowed to do often comes back to identity, access, and how much trust you’re placing in them.

That’s not a separate layer, but it touches every part of the stack.

Conclusion

If there’s one thing that stood out to me coming out of RSA, it’s that we’re still very early in how we think about securing AI systems.

The technology is moving fast, and the security models are still catching up.

But what’s becoming clear is that this isn’t going to land as a single product category.

As AI systems become more autonomous, the way we secure them is starting to look a lot more like how we secure complex systems today — layered, with controls at multiple points, not just one.

The challenge now is figuring out how those layers come together in a way that actually works in practice.  And if history is any guide, we’ll probably see a familiar pattern play out.

Startups will continue to emerge, each going deep on a specific part of the problem.

And over time, many of those capabilities will get pulled into broader platforms as larger vendors try to stitch together more complete solutions.

We’ve seen that movie before.