Before We Secure AI, We Need to Agree on What We’re Talking About

It’s been a minute since I posted here. I’ve been heads-down in the security trenches, but something has been eating at me that I need to get out in the open.

Every week, I’m in conversations with enterprise architects, security leaders, and IT directors who are all trying to figure out AI. And I keep running into the same problem: we don’t have a shared vocabulary. We’re using the same words to mean completely different things, and it’s creating real blind spots — especially when it comes to security.

So before the industry writes one more framework, one more best-practices guide, or one more “AI-powered” press release, I think we need to stop and define what we’re actually talking about.

Three Architectures, Three Threat Models

When someone says “we’re using AI,” that statement is almost meaningless without understanding where they sit on the deployment spectrum. From what I’m seeing in the market and in real enterprise conversations, there are three distinct architectural postures — and each one carries a fundamentally different security profile.

Embedded AI — This is AI you consume. Think Copilot in your Microsoft 365 suite, Salesforce Einstein, and AI features getting quietly baked into your existing SaaS stack. You didn’t build it. You didn’t train it. You don’t host it. Your vendor bolted it on, and one Tuesday morning it just showed up in your toolbar. IDC predicts AI copilots will be embedded in 80% of enterprise workplace applications by 2026. Gartner calls this the “Consume” approach. Whatever you call it, it’s AI that arrived without your architecture team getting a vote.

Integrated AI — This is the massive middle ground where most enterprises actually live today. You’re building custom applications — RAG pipelines, orchestration layers, AI-powered workflows — but you’re calling external model APIs from providers like OpenAI, Anthropic, or Google. You own the application logic, but the model lives somewhere else. Gartner calls this “Extend” or “Embed.” It feels like you built it, but your data is still crossing trust boundaries every time you make an inference call. This is also where agentic AI is taking off fastest — agents that chain together API calls, tool use, and autonomous decision-making across your environment.

Private AI (sometimes called Sovereign AI) — This is AI you fully architect, deploy, and control. You’re selecting and hosting open-weight models like Llama or Mistral on your own infrastructure or private cloud. You’re fine-tuning on proprietary data. The model, the data, and the inference pipeline never leave your boundary. This is where regulated industries — healthcare, financial services, defense, government — are increasingly heading. It’s also where the concept of “Sovereign AI” is gaining traction, with Gartner predicting 65% of governments will introduce technological sovereignty requirements by 2028.

These are fundamentally different architectural postures with fundamentally different security implications, and yet I watch people conflate them in every meeting. When your CISO asks, “Are we secure with AI?” — the answer depends entirely on where you sit on this spectrum. And increasingly, most enterprises operate across all three simultaneously, making it even harder.

Why This Matters Right Now

Each of these deployment models creates a different trust relationship, and most organizations haven’t clearly mapped those trust boundaries.

With Embedded AI, your threat model is essentially about trust delegation. You’re trusting your vendor’s data isolation. You’re trusting their model doesn’t leak your data into someone else’s completions. You’re trusting that the AI features they embedded into your existing tools didn’t just change your risk profile without anyone in your security team getting a say. That DEF CON research I wrote about a few months back — where researchers found authentication bypasses in every ZTNA platform they tested — is exactly the kind of misplaced trust that shows up when we outsource security assumptions to vendors.

With Integrated AI, the trust model gets murkier. You control the application, but every inference call sends data to an external model provider. Your RAG pipeline might be pulling from sensitive internal data stores and feeding that context into an API you don’t control. You’re managing API keys, token flows, and data-in-transit — and if you’ve built agentic workflows on top of this, those agents are making autonomous decisions about which tools to call and what data to pass. The attack surface is real, and it’s expanding.

With Private AI, your threat model looks more like traditional application security — but with new attack surfaces layered on top. Model poisoning. Prompt injection. Data exfiltration through inference. Insecure model serving containers. These are problems you own, and they require your architects to understand what’s running under the hood.

Agentic AI Doesn’t Care About Your Taxonomy

Here’s where it gets really interesting and really dangerous.

Agentic AI crosses these boundaries constantly. An AI agent might consume an Embedded AI feature, call an Integrated AI pipeline, query an internal database, and take action on an external system — all in one workflow. It moves across the Embedded / Integrated / Private spectrum without asking permission, and most enterprises have zero visibility into that crossing.

The numbers should get your attention. Palo Alto Networks is forecasting that autonomous agents will outnumber humans 82-to-1 in enterprise environments. CyberArk warns that every AI agent is an identity — it needs credentials, accumulates entitlements, and becomes a prime target for attackers. OWASP released its Top 10 for Agile Applications in December, specifically because Agile systems introduce risks that don’t fit neatly into existing frameworks. And NIST has an open Request for Information right now (comments due March 9, 2026) asking industry how to address security considerations for AI agent systems.

Meanwhile, only about 34% of enterprises report having AI-specific security controls in place, per Cisco’s State of AI Security report. We’re deploying agents at scale, while most organizations haven’t even mapped the architectural boundaries that those agents cross.

What Architects Should Be Doing Right Now

I’m not going to pretend I have all the answers. But I do think there are a few things enterprise architects should be doing today:

Map the spectrum in your environment. Not just “we use AI.” Identify what’s Embedded (consumed via SaaS), what’s Integrated (your apps calling external models), and what’s Private (fully self-hosted). You can’t govern what you can’t categorize.

Name the trust boundaries. For every AI capability, ask: who trained this model? Where does my data go during inference? Who controls the model updates? If you can’t answer those questions, you have a trust problem masquerading as an AI strategy.

Treat every agent as an identity. If you have agents making API calls, accessing data stores, and taking actions, they need identity governance just like any other privileged entity. Least privilege. Just-in-time access. Continuous authentication. The zero-trust principles we’ve been preaching for years apply here, perhaps more than anywhere else.

Get comfortable with the architecture, not just the outputs. I’ve talked to too many leaders who can tell me what their AI does but not how it works. You don’t need to be a data scientist, but you need to understand the difference between a fine-tuned model and a RAG pipeline, between a hosted inference endpoint and an embedded SaaS feature. These architectural differences create different risk profiles, and your security posture needs to reflect that.

The Conversation I Want to Have

I’m writing this because I think the enterprise architecture and security community needs more practitioners talking openly about what we’re seeing — not more vendor whitepapers, not more framework documents, but real observations from people who are in these conversations every day.

AI isn’t going to slow down, so we can figure it out. But we can at least agree on the vocabulary before we try to secure it.

I’ll be writing more here on what I’m seeing at the intersection of AI, architecture, and security. If you’re an architect or security leader wrestling with these same questions, I want to hear from you. Where are the gaps in your environment? What are you seeing?

Let’s figure this out together.