TL;DR: No comprehensive AI security reference architecture exists to buy today. So the most capable security teams are building their own from fragments, then handing that framework to vendors as a coverage grid. If you're still selling or presenting AI security education, you're arriving several steps behind where these buyers already are.
A security team at a global travel platform showed up to a call with something I didn't expect. They'd built their own AI Security Controls Framework: five environments across the top, control domains down the side, and a governance row cutting through all of it.
They weren't asking what AI security was. They'd already mapped their current state. What they wanted was help deciding what to fix first.
That's becoming the normal shape of a sophisticated buyer.
Why is there no AI security reference architecture to buy?
Because the category is younger than the demand.
Traditional security has decades of accumulated reference material. Network security has published architectures. Identity has maturity models. Cloud has well-documented shared-responsibility diagrams and CSA guidance built over years.
AI security has fragments. NIST has the AI Risk Management Framework, which is strong on risk process and deliberately not an architecture. OWASP has the LLM Top 10, which covers application-layer threats and doesn't address enterprise control planes. Cloud providers publish guidance shaped around their own services. The Cloud Security Alliance has done real work on agentic AI, and I co-chair one of those efforts, and even there the material is a set of components rather than a single blueprint you can hand an architect.
Every piece is useful. None of them is complete, and nobody has stitched them together into a thing you can hold up and say "this is the target state."
So teams that need a target state build one.
What does a self-built framework actually look like?
Usually a grid.
The travel platform's version had five environments across the top, meaning the distinct places AI runs in their estate: SaaS tools with AI features, an enterprise chat deployment, developer tooling, homegrown applications calling provider APIs, and agentic systems. Down the side went control domains: identity, data, monitoring, network, and so on. A governance row ran across everything.
Then each cell gets a status. Covered, partial, or gap.
That grid does three jobs at once. It's a current-state assessment, a gap list, and a vendor evaluation tool. Vendors get handed the same grid and asked which cells they cover. Suddenly a product demo becomes a coverage question with a right answer, and marketing language stops working.
It's a reasonable response to an incomplete market. It's also a signal about who you're talking to.
Why does this change how you should engage these buyers?
Because education lands as condescension when the buyer has already done the work.
If someone arrives with a controls framework they built themselves, the opening move can't be "here's why AI security matters." They've internalized that. They wrote a document about it. What they haven't solved is prioritization and target state, which is genuinely harder and where the value is.
The same pattern shows up in cost control. Teams arrive having already deployed spend caps and routing harnesses, and already disappointed by both. Meeting them with an introduction to AI cost management wastes the call, and it skips the harder question of what their ROI model leaves out. They need troubleshooting and architecture, not fundamentals.
I've started thinking of it as meeting the buyer at their fork. Some are still at "what is this," while others are at "which of these do I fix first," and a growing number are at "the thing I built isn't working and I need to know why." Those are different conversations, and picking the wrong one loses the audience inside five minutes.
What are self-built frameworks usually missing?
Three things, consistently.
A trajectory view. Grids are static. They tell you which controls exist in which environment. They don't tell you what an agent did across a sequence of actions, and sequence is where agent risk lives. Every individual cell can read "covered" while the run of actions across cells adds up to something nobody approved.
Identity for non-human callers. Most self-built grids inherit an identity row from the human-user world. Service accounts, API keys, and agent identities get folded into one cell, and that cell is doing far too much work. An agent identity needs an owner, a scope, and an expiry, which is the case for one accountable human per agent, and almost no grid has room for it.
Enforcement versus documentation. A cell marked "covered" often means a policy exists, not that a control refuses anything. That's governance existing while enforcement doesn't, and grids are bad at capturing it. Add a second column to every cell: is it written down, and does something enforce it.
If you've built a grid, those three are worth a pass before you take it to a vendor.
Where does Zero Trust fit?
Zero Trust is the foundation these grids should be built on, and often is. It verifies every request against identity, device, posture, and behavior signals, continuously and per request. Most self-built frameworks map cleanly onto it, because the pillars give you a sensible set of rows.
What Zero Trust needs added for agents is the sequence layer described above, plus a defined identity for non-human callers underneath it. You can't continuously verify an identity nobody ever specified. That's the layer beneath Zero Trust, not a flaw in it, and it's the part self-built grids most often leave thin.
What can you do this week?
If you're building or already have one of these:
Add an enforcement column. For every cell marked covered, record whether a control refuses an action or a document describes one. Expect the results to be uncomfortable.
Split the identity row. Human identities, service accounts, and agent identities are three different problems. One row hides two of them.
Add a sequence row. Ask, for each environment, whether anything watches what a caller did across multiple actions. Most answers will be no, and that's useful to know before an incident tells you.
Date every cell. A coverage grid with no dates decays silently. Six-month-old cells are guesses.
Take it to vendors as a grid, not a brief. Ask which cells they cover and which they don't. The ones that answer cleanly are worth more of your time.
If you're not building one yet, start with the environments list. Just naming every distinct place AI runs in your estate, honestly, is usually the finding.
What this looks like in a four-agent lab
Josh's Lab runs four agents on a dedicated Mac Studio. Atti orchestrates, Forge codes, Scout researches, Quill writes.
I built a controls grid for it, which felt absurd at four agents until I filled in the enforcement column. Several cells I'd have marked covered turned out to mean "I decided this in my head once." Forge's tool scope had changed at some point and nothing anywhere recorded that it had.
That's the author of a governance framework, running four agents, with a grid that looked complete and an enforcement column that was mostly empty.
The grid didn't lie. It just answered the question I asked it, and I'd been asking the easier one.
Key takeaways:
No comprehensive AI security reference architecture exists to buy. NIST, OWASP, cloud providers, and CSA each cover a piece.
Sophisticated security teams are building their own coverage grids and handing them to vendors as evaluation tools.
These buyers are past education. They need prioritization and target state, and the same holds for teams already disappointed by their cost controls.
Self-built grids consistently miss trajectory, non-human identity, and the gap between documented and enforced.
Adding an enforcement column to an existing grid is an afternoon of work and usually the most useful afternoon in the project.
Frequently asked questions
Is there a standard AI security reference architecture?
Not a comprehensive one. NIST's AI Risk Management Framework covers risk process, OWASP's LLM Top 10 covers application threats, cloud providers publish service-shaped guidance, and the Cloud Security Alliance has agentic AI work underway. Each is useful and none is a complete blueprint, which is why teams assemble their own.
What is an AI security controls framework?
Typically a grid: the environments where AI runs across the top, control domains down the side, and a coverage status in each cell. Teams use it as a current-state assessment, a gap list, and a vendor evaluation tool at the same time.
What should be in the environments list?
Every distinct place AI runs in your estate. SaaS tools with AI features, enterprise chat deployments, developer tooling, homegrown applications calling provider APIs, and agentic systems are the common five. Building that list honestly is often the most revealing step.
What's the most common gap in a self-built framework?
The difference between documented and enforced. A cell marked covered frequently means a policy exists rather than a control refuses something. Adding a second column for enforcement surfaces the real gap fast.
Should I share my framework with vendors?
Yes. Handing a vendor a coverage grid and asking which cells they cover converts a demo into a specific answer. It also filters quickly, because vendors who can't map to your grid are usually selling something adjacent to your problem.
How do agents change the grid?
They add a dimension a static grid doesn't have. Agent risk accumulates across a sequence of individually permitted actions, so a row asking what watches a caller's trajectory belongs alongside the rows asking what permits each action.
The market hasn't produced the blueprint yet, so the best teams are drawing it themselves. If you're one of them, the fastest improvement to the drawing you already have is a second column asking whether anything actually enforces the cell you marked green.