Not All AI Agents Are Built the Same: A Field Guide to Enterprise Readiness

I just got back from RSA, and one thing became clear: while everyone is talking about "AI Agents," almost nobody is talking about the same thing.

One booth was focused on securing LLM wrappers with a few tool integrations. Another was focused on capturing API traffic from agents built and hosted in-house. Both are valid pieces of the picture. But very few were talking about third-party hosted agents, or the low-code and no-code agents that business units are already using to spin up "digital workers" without ever involving Engineering.

We've officially moved past the "Year of the Model" and into the Year of the Agent. But this explosion of variety is exactly why the security conversation feels so fuzzy. Before we ask if an agent is "secure," we have to stop treating "AI Agent" as they are all the same.

To bridge the gap between RSA hype and enterprise reality, we need to be precise about what kind of agent we're actually deploying. I find it most useful to break agents down across three technical dimensions: where they run, how they operate, and how they are built.

The Three Dimensions of Agency

1. Where the Agent Runs: SaaS vs. VPC vs. Edge

The hosting model effectively dictates the "visibility horizon" for a security team. It determines who owns the steering wheel when an agent starts making decisions in the real world.

● External / SaaS Agents: These are the easiest path for business units because the vendor manages the runtime and orchestration out of the box. Not surprisingly, this is also where adoption is moving fastest. AI-native tools are already spreading across CRM, accounting, legal, and customer operations because they promise quick deployment and fast ROI. But that convenience comes with a real tradeoff: a bring-your-own-security-policy gap. The enterprise can configure the agent, but it does not control the execution environment. What exactly do you secure here? From the buyer side, the question is whether the organization can apply its own runtime policy around data access, tool use, and downstream actions. From the SaaS vendor side, the security challenge is whether the platform can support customer-specific control, tenant isolation, auditability, and regional or vertical compliance at scale.

● VPC-Resident Agents: These live inside your own cloud, giving you more control over networking, identity, logging, and monitoring. Builders like this model because it works well with internal APIs, enterprise data, and open-source models. But that control comes with responsibility. Being in-house does not mean an agent is governed. It means the enterprise has more control over where policy is applied, how behavior is monitored, and how runtime enforcement is implemented. What exactly needs to be secured here? Both the LLM layer and the tool layer. Prompt and output guardrails are still necessary, but they are only part of the picture. The enterprise also has to control what the agent can retrieve, which tools it can invoke, what systems it can change, and what conditions it should block, redact, or monitor. As these systems grow more complex, real-time risk assessment and context-aware monitoring become critical for understanding intent and enforcing policy at runtime.

● Local/Edge Agents: Running directly on hardware — like Apple Intelligence or Copilot+ PCs — these can be strong for privacy and responsiveness. But they also raise a practical governance question: where does runtime enforcement happen? If the agent sits outside the enterprise control plane, it becomes difficult to apply the organization's own security policy consistently, and that can quickly drift into shadow AI.

2. How the Agent Operates: Interactive vs. Background

The second distinction is how the agent operates.

● Interactive Agents: These agents sit beside the user in a chat window, sidebar, or embedded workflow. The person can see the output, review the recommendation, and decide whether to take the next step. That does not eliminate risk, but it does keep the human in the control loop. What exactly needs to be secured here? The same runtime controls still apply, but context becomes critical. The enterprise needs to ensure the agent stays within its intended mission, does not drift based on the user's prompt, and does not act on malicious or unsafe instructions.

● Background/Autonomous Agents: Other agents run in the background. They trigger on events, schedules, or workflows without a person watching each step. And the moment that human checkpoint disappears, the risk profile changes. These agents can no longer be treated like simple assistants. They need to be treated more like operational systems, with tightly scoped permissions, machine identities, and runtime controls around what they are allowed to do.

3. How the Agent Is Built: Low-Code vs. Wrapper vs. Custom

The way an agent is born usually determines how much structure — or chaos — surrounds it long-term. This isn't just a technical choice; it's a choice about who owns the logic and who can step in when it breaks.

● Low-Code/No-Code Agents: This is the biggest shift in the market right now. Business teams are using visual builders and prepackaged connectors to assemble "digital workers" in hours rather than months. While this speed accelerates adoption, it often creates a governance black box. Because the orchestration logic is abstracted away from IT, security teams often have zero visibility into the actual decision-making steps the agent is taking. In these cases, what matters most is runtime control: visibility into activity and tool access, plus a real-time kill switch when the agent crosses a policy boundary.

● Prosumer or Wrapper-Based Agents: These are the lightweight, "app store" style tools like Custom GPTs or Anthropic's Claude Projects. They are usually built by individuals or small teams using prompts and packaged APIs rather than a full enterprise stack. While they are fantastic for rapid experimentation, they represent a significant governance hurdle. Organizations often try to secure these by putting an AI Firewall in front of them, but that typically only governs the prompt and response path. It fails to address the "downstream" risk: the tool access, identity scoping, and data-handling rules that these "thin wrappers" use to touch enterprise systems. What needs to be secured is not just the prompt, but the full action path behind it.

● Custom Engineered Agents: These are built code-first by developers using frameworks like LangChain or internal APIs. This is often the most mature path, offering the deepest integration and flexibility, but it requires more engineering effort and takes longer to ship. From a security standpoint, they should be treated similarly to VPC-resident agents: more control over the runtime, but also more responsibility to govern it well.

Summary: Highest-Priority Governance Patterns

This table highlights the most important control patterns across the agent types above rather than repeating every category one by one.

Browser-Based Agents: Worth Noting, Still Early

These are worth including for completeness, but they still feel early for enterprise use. Browser-based agents may be popular for individual productivity, but Gartner has taken the unusual step of recommending enterprises block or pause them for now. They act through the user's live browser session, creating a confused deputy problem: the agent is effectively operating with the user's authority, not its own tightly scoped identity. And as these agents begin moving context across tabs, the risk is no longer just the prompt. It is what the agent can see, carry, and do across already authenticated applications. Same-Origin Policy (SOP) was built to isolate websites, but it was never designed to govern autonomous agents acting across already authenticated sessions. That is why prompt filtering alone is not enough.

Conclusion

As agents move from answering questions to taking action, the security conversation has to move with them. The focus can no longer stop at securing the model — filtering prompts, blocking jailbreaks, or catching unsafe outputs. The harder and more important problem is governing the action: what the agent is allowed to access, what it is allowed to do, and where the enterprise can enforce its own policy at runtime.

That shift is already starting. Enterprises accepted bring your own key because they wanted more control over how their data was protected. They will ask for the same thing here: the ability to bring their own security policy to agentic systems that act on their behalf.

That is why enterprise readiness is not a feature, a demo, or a model benchmark. It is a state of governance. Whether an agent is vendor-hosted, built inside a VPC, assembled in a no-code platform, or running in the background with no human watching, the real question is the same: who holds the steering wheel when the agent starts acting in the real world?

Once we separate agents by where they run, how they operate, and how they are built, the path becomes much clearer. Not all agents are the same. They should not be governed the same way. And they do not become enterprise-ready on their own. They become enterprise-ready only when the organization can see them, control them, and apply the right policy while they act.

Thank you for following along. In my next piece, I'll dive deeper into the different approaches to securing agentic applications, and the pros, cons, and tradeoffs to watch for. Happy reading.