AI Risk Is Not Uniform: The Case for Archetype-Aware Enterprise Security

Every conversation I have with security leaders about enterprise AI security eventually arrives at the same place: a description of what they've extended. Their data loss prevention tool now flags sensitive data going into prompts. Their SIEM is ingesting AI platform logs. Their cloud security team has added model endpoints to their coverage scope. For many teams, this represents real effort and real progress.

What those programs almost universally lack is a structural framework for what they're actually securing. Enterprise AI isn't one problem with multiple solutions: it's five fundamentally different deployment patterns, each with its own threat model, attack surface, and governance requirements. And the typical large enterprise isn't running one of them. It's running all five.

This is the archetype problem. Until security programs are built around it, coverage gaps are structural, not incidental. The framework for thinking through this clearly comes directly from Zenity's recently published Definitive Guide to AI Security, which maps the full AI security landscape, including lifecycle phases, industry categories, deployment archetypes, and the controls every enterprise program must understand.

This piece pulls out the framing I think matters most before you work through the guide in full.

What We Mean When We Say "Enterprise AI"

The most common error in enterprise AI security programs is treating AI as a single, definable attack surface, a technology to be secured and a category to address in the next risk review cycle. In practice, enterprise AI spans five deployment archetypes with risk profiles that don't overlap.

Embedded AI Systems are the most widely deployed. These are the AI copilot and assistant features built into enterprise SaaS platforms, such as Microsoft 365 Copilot, Salesforce Einstein, Slack AI, Google Gemini for Workspace, and ServiceNow Now Assist. They're vendor-managed, already inside the most sensitive systems in the organization, and often the least governed precisely because business users interact with them daily while security teams lack visibility into what data those interactions are touching.

The primary threat vectors are sensitive data exposure through AI-generated outputs, indirect prompt injection through documents and emails the AI is summarizing, and privilege escalation when the AI acts on a user's behalf.

Democratized AI Systems are built by business users and citizen developers using low-code and no-code platforms, such as Copilot Studio, Agentforce, n8n, Google Workspace Studio, and Box Agents. Unlike embedded AI, these agents aren't just answering questions. They're taking real autonomous actions, sending emails, updating records, calling APIs, and reading shared drives. They're often deployed without security review, created by people who understand the business workflow but not the permissions model.

Overprivileged agents, prompt injection at the agent layer, and data exfiltration through unmonitored external API calls define this archetype's risk profile.

Homegrown AI Systems are custom agentic pipelines built by internal engineering teams using AI SDKs, orchestration frameworks, and cloud AI APIs, such as LangChain, CrewAI, LangGraph, AWS Bedrock, Google ADK, and the Anthropic API. These systems have the deepest integration with enterprise data and infrastructure. They can query internal databases, call internal APIs, and orchestrate multi-step workflows across systems.

The blast radius if one is compromised is correspondingly large. The introduction of MCP and A2A protocols has expanded the attack surface further, creating supply chain and inter-agent communication risks that traditional security tooling doesn't reach.

Device-based AI Systems are coding agents and personal AI tools running directly on developer endpoints, such as Cursor, GitHub Copilot, Claude Code, Windsurf, and Perplexity Comet. This is the fastest-growing archetype and the one creating the most acute visibility gap for security teams, who typically have no insight into what models are running locally, what code is being generated, or what external services the agent is connecting to through MCP servers inside the corporate network.

Code and sensitive data exfiltration, lateral movement via MCP, and AI SDK supply chain compromise are the defining risks.

Homegrown Models are internally fine-tuned or trained AI models deployed through private registries. Most common in regulated industries and large enterprises building proprietary AI capabilities, including fraud detection, compliance screening, and customer behavior modeling. The risks here are unique: training data poisoning, model inversion attacks, adversarial inputs, and behavioral drift that doesn't manifest until the model is already in production. A clean model doesn't make a secure agent. It's one input into a system that still needs to be governed and controlled at the point where it acts.

No enterprise runs just one of these. A representative large enterprise today has Copilot deployed across Microsoft 365, citizen developers building agents in Copilot Studio, engineering teams running Bedrock pipelines, developers using Cursor locally on laptops connected to the corporate network, and a data science team fine-tuning proprietary models. Each carries a different threat model. Each requires a different security approach. Most security tools are built to address just one.

Why the Controls Don't Transfer

There's a structural problem with extending existing security tooling to cover AI across all five archetypes: identity, data, cloud, endpoint, and network controls aren't AI security solutions. They're context inputs for what the agent decides to do.

The agent is the enforcement point. It's where AI takes on real-world risk: what accesses your data, calls your APIs, and executes decisions your organization is responsible for. No single control secures the agent in isolation, because the agent's behavior isn't determined by any one of those systems. It's shaped by the combination of all of them, and by inputs, including prompts, retrieved documents, tool outputs, and inter-agent communications, that none of those systems were built to inspect.

This plays out differently across each archetype. The controls that matter for Embedded AI, including configuration auditing, data leak prevention at the prompt and output layer, and behavioral anomaly detection inside SaaS platforms, are not the same controls that matter for Homegrown AI. A pipeline built on LangChain needs supply chain validation of every model and SDK dependency, automated red-teaming before deployment, runtime monitoring for prompt injection through retrieved documents, and inter-agent communication controls when that pipeline calls another agent. The attack surface is categorically different. The governance requirements are categorically different.

The threat vectors for Device-based AI, including code exfiltration, lateral movement through MCP servers, and AI SDK supply chain compromise, have almost nothing in common with the threat vectors for Homegrown Models, where the concerns are training data lineage, adversarial robustness, and detecting behavioral drift before it affects production systems.

Intent is not control. An organization that has approved the use of AI tools and extended its existing security stack to monitor them has done something. What it hasn't done is govern what those agents do, what they access, and whether their behavior stays within bounds at runtime. That's the gap most programs are sitting in.

What Practitioners Should Do Differently

For security leaders building or maturing an AI security program, the archetype-first framing has three immediate practical implications.

First: inventory your archetypes before you inventory your tools. Before you can assess coverage gaps, you need to understand what's actually running. Most organizations have a reasonably clear picture of their Embedded AI footprint, specifically the SaaS vendors IT has enabled, and almost no visibility into Democratized AI being built by business units, Homegrown AI pipelines under construction in engineering, or Device-based AI running on developer endpoints.

Second: assess your controls against each archetype's threat model, not against AI in the abstract. Ask:

• Do we have runtime controls for autonomous agents taking real-world actions?
• Do we have supply chain validation for AI SDK dependencies in our engineering environments?
• Do we have behavioral monitoring for models that may have drifted from their intended function?

These are different questions, with different answers, for each of the five archetypes. Answering them in aggregate produces a false sense of coverage.

Third: recognize that from build time to runtime, the enforcement point is the agent. Identity, data, and cloud controls inform the picture; they don't constitute it. The agent is what accesses your data, calls your APIs, and takes actions your organization is responsible for. Governing the full set of inputs that shape what the agent does, across every archetype and every phase of the AI security lifecycle, is what an enterprise AI security program actually has to cover.

For the complete framework, including archetype-by-archetype control breakdowns, the full six-phase lifecycle map, and the capabilities every enterprise program must understand, download the Definitive Guide to AI Security by Zenity.