TL;DR
- “Are we secure against AI agents?” can’t be answered as asked. It bundles ten different problems—with ten different owners—and no shared vocabulary to separate them.
- AI didn’t add a new attack surface the way cloud or BYOD did. It invalidated nine assumptions enterprise security has rested on for decades, including that humans make decisions, that identity maps to a human actor, and that execution is deterministic.
- Our new whitepaper splits the problem in two. Six control planes show where control is kept or lost, and ten risk domains show where the problems surface.
- The ten domains double as board reporting lines and as cross-functional working groups.
James Shank, our Director of Threat Operations, kept getting a version of the same question. Sometimes from customers, sometimes from executives, sometimes from his own team.
“Are we secure against AI agents?”
It’s a fair question. It’s also close to unanswerable, because it isn’t just one question. Buried inside it are ten different problems with ten different owners, and all of those problems come with their own sets of terms and rules.
If you answer it in terms of data governance, you’ve skipped identity; answer it in terms of prompt injection, and you’ve skipped what your vendors do with your logs.
“The questions we were getting didn’t have enough definition to answer,” Shank says. “AI touches so many parts of operations that it breaks the old paradigm of one or two control assessments.”
So we wrote down the framework we’d been reaching for. It’s a strategic risk model for AI security, and it’s built for the conversation between a CISO and a board, and between a CISO and the teams who have to do the work.
Every new technology gets absorbed. This one didn’t.
Security is always playing catch-up, and we’re good at it. The move to cloud, the arrival of software-as-a-service (SaaS), bring your own device (BYOD), mobile device management, and all the rest: each one arrived, each one looked like a crisis, and each one eventually got folded into existing playbooks. New surface, same fundamentals.
AI is different, and the reason is specific: It invalidated assumptions the enterprise security model has rested on for decades.
As it stands, cybersecurity generally applies the following assumptions to its practices:
- Humans make decisions.
- Identity maps to a human actor.
- Data movement and provenance are clear.
- Execution is deterministic.
- Intent and action are directly linked.
- Observability is sufficient for reconstruction.
- Time exists between attack phases.
- Vendors are infrastructure providers rather than decision-makers.
- There are clear accountable parties.
Just one of these breaking would be a manageable project—a control review, a policy update, a new tool. All nine breaking at once, however—from a single technology shift—is a different kind of problem. Security operations can’t absorb that alone. Some of it calls for architecture changes, and some of it calls for protocols and controls that don’t exist yet. This framework is meant to be a tool to help you close that gap for your organization.
Two halves: Where risk shows up, and where you can act
The model has two parts: six control planes, and ten risk domains.
The six control planes describe where control is maintained or lost: data, identity, execution, human, external AI and service, and observability. These aren’t new. What’s new is how central they’ve become to answering the question “Who needs to be in this room?” When you pull a cross-functional group together to address an AI risk, the control planes tell each person why they were invited.
The ten risk domains describe how the risk actually surfaces:
- Data exposure and control breakdown
- Identity, authorization, and boundary degradation
- Instruction manipulation
- Vulnerability discovery and exploit acceleration
- Attack chain compression
- Post-compromise intelligence amplification
- Human trust and business process exploitation
- Defender operating model disruption
- External AI and SaaS control loss
- Observability collapse
Each domain spans several control planes, which is exactly why AI risk can’t be handed to one owner and closed out. The domains are distinct enough to analyze and report on separately, but they reinforce each other. Observability gaps hide instruction manipulation. Identity degradation lets execution happen at scale. Attack chain compression removes the window you’d need to respond to any of it.
We’re not presenting the ten in priority order, and we don’t think every organization should weight them the same way. Your appetite and your architecture decide that.
Three shifts underneath all ten domains
If you only take three things from the paper, take these.
- Identity has been degraded. Not just as an authentication mechanism, but as a boundary, an authorization model, and a basis for accountability. Agents act across systems with combined permissions; privilege boundaries get traversed through workflows instead of logins. The legal question of who is responsible for an action gets genuinely hard.
- Execution stopped being deterministic. It’s probabilistic, and therefore subject to interpretation. The same input doesn’t reliably produce the same output, which breaks a quiet assumption inside most of our detection logic and most of our incident response processes.
- Observability is no longer a question of whether you have the logs. You might have all of them and still not be able to prove who acted, what they acted on, or what they intended. Traditional logs don’t capture reasoning or decision paths. If activity can’t be reconstructed, it can’t be secured, which is why observability has moved from a supporting function to the foundation the other five planes are validated against.
How to actually use it
The ten domains double as reporting lines. Walk your board through how you’re addressing each one and you’ve given them a picture that holds together, in language that doesn’t require them to understand the deep technicalities of each.
Downstream from the board meeting, each domain becomes a working group. The whitepaper includes a full walk-through of domain 1—data exposure and control breakdown—as an example, to show what that looks like in practice. This includes who owns what across security architecture, data governance and privacy, legal, and AI engineering; which operational metrics tell you whether you’re improving; and where the mitigation checkpoints sit in a retrieval pipeline. From that output, work can be sized, scoped, and commissioned.
That’s the whole goal here. Take the uncertainty AI introduced and turn it into governance somebody owns, measures, and reports on.
You can access the framework here.
