The KuppingerCole AI Security Reference Architecture describes 68 capabilities across five functional groups. Most vendor blueprints for securing AI agents cover a fraction of that.
That gap is why we are introducing the AI Security Fabric. The question I hear most is not which tool secures AI agents. It is why we cannot simply extend the Identity Fabric and treat agents as first-class identities. My short answer: identity is necessary, but it is not sufficient. In the latest Analyst Chat, along with Matthias Reinwarth and Phillip Messerschmidt, we explain the reasoning.
Same method, different angle
The Identity Fabric works because it starts from requirements, not products. You define what you need, map it to capabilities, group capabilities into services, and only then choose tools. The AI Security Fabric keeps this logic. Business requirements come first, security requirements are derived from them, and tools come last. The aim is to assemble solutions like Lego bricks from what you actually need, not to buy one product and hope it solves everything.
What changes is the perspective. As Phillip put it, this is closer to an extension than a second version of the same fabric: the same concept viewed from the angle of AI security. The overlap with identity is real, but the AI Security Fabric covers much more, including AI safety and protection.
Why the Identity Fabric alone is not enough
Three differences explain why AI security needs its own fabric.
1. The scope is broader than identity. AIdentity is one of five functional groups, with 14 of the 68 capabilities. The others are AI Governance (14), AI Safety (13), AI Protection (14) and AI Transparency (13). The classic controls built for humans do not fully secure agent actions. That is why the architecture is organized around the pillars that secure what an agent does, not only who it is.
2. The stakeholders are different. AI security, cybersecurity, IAM and development teams each hold different accountabilities and see different parts of the problem. A single identity-centric view does not give them a shared model.
3. The ambition is deliberately wider than the market. Vendor blueprints tend to cover what the vendor sells. Our ambition is to go broad. That includes capabilities organizations will need but for which there is hardly a good solution on the market yet. A capability-first model makes those blind spots visible.
The Advisory Note AI Security Fabric: Introduction and Overview makes the same point: AI security is an architecture and ownership problem before it is a procurement problem. No single product category covers identity, governance, runtime control, security and accountability for agents at once.
“One home per capability” keeps fabrics from colliding
Once you run more than one fabric, such as identity, AI security and the Cybersecurity Fabric to come, you risk duplicated capabilities and conflicting ownership. The new principle we introduce is “one home per capability.” A capability can appear in several fabric perspectives, but exactly one fabric is its primary home. It is borrowed and specialized elsewhere, not copied.
Authentication is the clearest example. If you already operate an identity provider and authentication methods for employees, consumers and service accounts, agents should build on them. That capability belongs to the Identity Fabric. The AI Security Fabric borrows it and specifies how it must work for agents.
There is a catch, and we should not underestimate it. Agents authenticate far more often and at far greater scale than a human who logs in once or twice a day. The consuming side changes the requirements on the service providers. This is why the principle pairs with another: services follow the organization. Each service needs an organizational anchor. That pushes organizations toward real service-delivery thinking, identity and security as a service, at the speed the business now expects.
From concept to a usable architecture
The fabric is the high-level blueprint. The reference architecture, which Phillip just released, makes it actionable. The Advisory Note AI Security Fabric and Reference Architecture sets out the 68 capabilities in a tool-neutral model:
- Layers: 28 core, 25 extended, 8 integration and 7 privileged capabilities.
- Supporting structure: an API layer and a shared foundation, including a registry data model and policy-as-code.
- Intended use: to design, assess and evolve AI security architecture, and to select tools last.
One piece of community feedback stood out. People were surprised by the number of pillars, and some pillars are rarely considered when organizations implement agent capabilities.
What to do with it
The recommendations from the episode and the Advisory Notes translate into concrete steps:
- Start from business requirements. Derive the security requirements from them and keep tools out of the conversation until capabilities are defined.
- Use the reference architecture as a checklist. Walk through the capabilities to find the areas you have not considered, especially the pillars beyond identity.
- Decompose vendor offerings into capabilities. Map what each product delivers, where it fits, and where it leaves blind spots.
- Reuse what you already have. Build agent authentication on your existing identity provider, and specify explicitly what changes for agents, such as frequency and scale.
- Name a home and an owner for each capability. Align AI security, cybersecurity, IAM and development around services, not around tools.
- Prioritize over time. Build a roadmap and set investment priorities by capability. A single “solve everything” purchase will not work, and the capability set will keep evolving with the speed of AI.
This is not the last fabric
The fabric approach started with identity and now extends to AI security. The Cybersecurity Fabric is next, and the one-home principle is designed to scale beyond that. A business application fabric, for example, could draw SAP security from the cybersecurity fabric and AI-specific controls from the AI Security Fabric. The result is a service model that spans the whole IT organization, not just a better way to secure agents.
Not managing it is not an option
AI agents are already in use. Governance and security have to keep pace. If you cannot say today which capabilities protect the actions your agents take, and who owns each one, that is your starting point.
The fabric is a map. Using it on your own agents is the harder part, and that is where we can help.
Become a KuppingerCole member: Most of our research is reserved for members, including both AI Security Fabric Advisory Notes and the analyst inquiries behind them. Explore memberships to read the full reference architecture and get direct access to the analysts who wrote it.
Work with our advisors: If you want to map your agents against the 68 capabilities, find your coverage gaps, and build a roadmap, talk to a KuppingerCole advisor. They help you start with the core, extend by risk, and choose tools last.
Not ready yet? Watch the Analyst Chat first. Then decide which agents to classify this quarter.
