Demystifying Agentic AI: You're Defending The Wrong Thing

The AI security conversation has a fundamental blind spot. Organizations are debating guardrails and governance for enterprise agents they spent months building, while ignoring the unmanaged AI infrastructure developers install in seconds with access to production credentials. This is not some nuanced trade-off between security and innovation, but a complete misunderstanding of where the actual threat lies.

The problem starts with terminology. The industry uses "agentic AI" as a catch-all term that conflates three entirely different security problems:

• Shadow AI: Unsanctioned MCP servers used by developers
• SaaS agents: Commercial platforms like OpenAI's AgentKit
• Enterprise agents: Your own implementations on Bedrock, Vertex, or AI Foundry

These require fundamentally different security strategies. Shadow AI is an external threat you need to defend against. Enterprise agents are internal assets you need to govern. Treating them the same way is causing organizations to allocate security resources backwards.

Breakdown of Agentic AI categories

In this post I try to reframe the conversation around what actually matters: identity and access management. An agent without credentials is just a chatbot. Agency requires the ability to act, and action requires non-human identities with permissions. Once you see it through this lens, the misallocation of security effort becomes obvious, and the path forward becomes clear, though uncomfortable.

Agency: A Definition

a·gen·cy | /ˈājənsē/ | noun

1. The capacity of an actor to act in a given environment.
2. The ability to make decisions and take actions that produce effects.

In the context of AI systems, agency is not about sentience or consciousness. It's about capability. An agent is software that can act on systems and data. But unlike traditional software, with agency the actions aren't hardcoded, but determined at runtime based on reasoning about context, goals, and available tools.

Strip away all the AI hype and here's what agentic AI actually is: software that makes decisions and takes actions --> Those actions require access to systems and data --> That access requires authentication and authorization --> Authentication and authorization require identity. Hence:

Agency is an identity problem.

Let me repeat that. An agent without credentials is just a chatbot. It can generate text, answer your questions, and help you think through problems. But it cannot act. It cannot read your database, call your APIs, modify your infrastructure, or interact with your systems. The moment you want an agent to do something useful, automate a workflow, analyze data, integrate systems, you need to give it an identity with permissions.

This is why the agentic AI security problem is fundamentally an IAM problem dressed up in AI clothing. Every agent that can act requires credentials. Every credential is an attack vector. Every attack vector needs governance.

The Three-Layer Taxonomy That Actually Matters

Agentic AI exists in three distinct layers, each with radically different security implications and threat models.

Shadow AI: The Unmanaged Threat

Shadow AI represents unsanctioned AI infrastructure that developers install without approval. The most common form is MCP (Model Context Protocol) servers, small programs that give AI models like Claude or GPT the ability to interact with local systems, read files, execute commands, and access APIs. A developer can install one with a single command like npx @modelcontextprotocol/server-filesystem and in under five seconds have external AI infrastructure running with access to whatever credentials exist in their environment.

These servers aren't reviewed by security teams, they're not in your asset inventory, and they inherit ambient permissions from the developer's workstation. They're distributed as npm packages or GitHub repositories by third-party developers you've never heard of, and your organization has zero control over their code, their infrastructure, or their update cycle.

SaaS Agents: The Third-Party Risk

SaaS agents are commercial AI agent platforms like OpenAI's Assistants API, Anthropic's agent offerings, or specialized agentic platforms. These are sanctioned services that your organization might have contracts with, but they operate on external infrastructure. You have limited visibility into how they process data, limited control over their behavior, and you're dependent on the vendor's security posture.

Enterprise Agents: The Managed Asset

Enterprise agents are AI systems you build and deploy on your own infrastructure: AWS Bedrock agents, Google Vertex AI agents, Azure AI Foundry implementations, or custom agentic systems running on AgentCore or similar frameworks. These take months to build, go through formal architecture reviews, require security sign-off, and run in your VPC or cloud environment. They use IAM roles you explicitly provision, they're subject to your network policies, and they show up in your monitoring dashboards.

The Critical Distinction

The defining characteristic isn't the sophistication of the AI model. It's ownership, control, and barrier to entry.

Shadow AI is external infrastructure with a five-second installation time, while Enterprise agents are internal infrastructure with a six-month development cycle. Shadow AI inherits whatever credentials happen to be available, while Enterprise and SaaS agents use explicitly provisioned credentials. Shadow AI is something you need to protect against. Enterprise and SaaS agents are assets you need to protect.

The security strategies are opposite, yet the industry treats them as the same problem.

What The Industry Is Missing

Some in the security industry are responding to the MCP conversation by focusing on how to secure MCP servers themselves. Building wrappers for secret management, implementing rotation mechanisms, hardening configurations. This entirely misses the point.

In enterprise environments, developers aren't building MCP servers. They're downloading them from public repositories. Let's take the command npx @modelcontextprotocol/server-slack. When a developer runs this command, they're executing third-party code from npm. The security question we need to ask therefore is not "how should MCP servers handle secrets safely?", but "should unvetted third-party code have access to production credentials at all?"

You cannot engineer your way around the fundamental problem: executing untrusted code with production credentials. The focus needs to shift from "how do we make this safer?" to "how do we prevent this entirely?"

The Shadow AI Threat: Credential Exposure at Scale

Shadow AI breaks every assumption your security controls are built on. Credentials are provisioned to known entities, those entities are in your inventory, and access is governed through policies you control. MCP servers bypass all of this.

When a developer installs an MCP server, they're not creating a new identity in your IAM system. The server doesn't get its own service account with scoped permissions. Instead, it inherits the developer's ambient credential context. AWS credentials configured for debugging production issues, database connection strings in .env files for local testing, GitHub personal access tokens for pushing code. The MCP server gets all of it.

Let's walk through what actually happens. A developer executes the following command: npx @modelcontextprotocol/server-filesystem

Once executed, the server starts. Immediately, it has access to the developer's entire filesystem, including juicy locations like:

• ~/.aws/credentials with AWS access keys
• ~/.kube/config with Kubernetes cluster credentials
• ~/.docker/config.json with container registry authentication
• Any .env files containing database passwords and API keys

The server can read the developer's entire filesystem, including any AWS access keys, Kubernetes cluster credentials, container registry authentication, or any .env files containing database passwords and API keys that happen to be on that machine.

The developer asks their AI: "help me debug why the API response is slow." The AI model, through the MCP server, reads the .env file, extracts the database connection string, connects to production, and runs queries to understand the schema. All of this happens automatically, driven by natural language interpretation.

Your security stack sees normal developer activity. The EDR logs a Node.js process. Network monitoring sees HTTPS to legitimate AI APIs. Database logs show queries from a developer machine's IP. Nothing triggers an alert because every individual component looks legitimate.

So What?

Here's where it gets dangerous. MCP servers are proliferating across multiple "marketplaces" and community repositories. GitHub repos, npm packages, Claude desktop configs shared on forums, and informal MCP server exchanges. Developers browse these collections looking for productivity gains. "Awesome Salesforce MCP," "Ultimate GitHub Integration," "Super Postgres Helper." The majority are legitimate, built by well-meaning developers trying to solve real problems.

But not all of them.

An attacker publishes an MCP server that does exactly what it promises. "Enhanced Salesforce MCP" genuinely provides better Salesforce integration. It works perfectly, gets GitHub stars, shows up in community recommendations. Developers install it because it solves their problem. What they don't see is the additional code that runs on first execution:

The Salesforce functionality works flawlessly. The credential exfiltration happens once, silently, during initialization. The developer uses the MCP server for weeks, never knowing their Salesforce credentials and AWS keys left their machine on day one.

This isn't theoretical. Malicious MCP servers exist in the wild right now. They masquerade as productivity tools, they deliver on their promised functionality, and they siphon credentials in the background. Your security controls see authorized developers running tools from community-recommended sources. The barrier to entry for both installation and attack is so low that it doesn't trigger your threat detection.

From the developer's perspective, they're using a productivity tool that everyone in the community recommends. From your IAM perspective, this is unvetted third-party code with arbitrary execution privileges, zero audit trail of credential access, and direct exfiltration to attacker infrastructure. The developer sees improved Salesforce productivity. You see a credential compromise you didn't detect until the breach notification arrives.

Enterprise and SaaS Agents: Different Threats, Different Controls

Now let's address enterprise and SaaS agents. These deserve serious security attention, but the threat models are fundamentally different from Shadow AI.

Enterprise Agents: The Governance Challenge

Enterprise agents running on AWS Bedrock, Google Vertex AI, or Azure AI Foundry are corporate infrastructure you own and control. They go through architecture reviews, security assessments, and formal IAM provisioning. They run in your VPC, subject to your network policies, visible in your monitoring dashboards.

The security challenges are real and substantial. Scoping permissions for probabilistic reasoning systems is genuinely difficult. How do you grant minimum necessary permissions when you can't predict exact action sequences? Traditional IAM policies struggle with dynamic, context-dependent behavior. You end up either over-privileging agents or building complex runtime authorization layers.

Input validation is another challenge. Prompt injection is the AI equivalent of SQL injection. If your agent processes untrusted user input without sanitization, malicious instructions can be hidden in the input and executed as legitimate commands. This requires new detection approaches and validation patterns.

Monitoring agentic behavior for anomalies needs sophisticated baselines. Traditional security monitoring assumes deterministic application behavior. Agents make probabilistic decisions based on natural language. Building effective behavioral analytics requires understanding normal reasoning patterns and detecting malicious deviations.

These are important, challenging problems. They deserve investment and attention. But they're manageable because you control the infrastructure, you own the identities, and you have visibility into behavior. Most importantly, you can shut them down if something goes wrong.

The threat model includes over-privileged provisioning (solvable through IAM governance), input validation failures (addressable through secure development practices), and operational risks (managed through monitoring and testing). These are not trivial challenges, but they're within the scope of traditional security controls applied to a new technology paradigm.

SaaS Agents: The Third-Party Risk

SaaS agents introduce supply chain considerations. You're granting credentials to external platforms. OpenAI's Assistants API, Anthropic's agents, and commercial platforms all require API keys or OAuth tokens that give them access to your systems. You're dependent on their security posture, their data handling practices, and their incident response capabilities.

The threats include credential exposure to the vendor (what happens if they're breached?), data exfiltration (your business data is processed on their infrastructure), and limited visibility into how your credentials are used. You have contractual protections and audit rights, but you don't control the infrastructure.

The mitigation strategy involves rigorous vendor assessment, scoped credential provisioning with minimum necessary permissions, monitoring API usage for anomalies, and contractual data protection requirements. It's classic third-party risk management applied to AI agents.

Both enterprise and SaaS agents require serious security effort. The difference is that you have leverage. You control provisioning, you can monitor behavior, you can revoke access. These are assets you're actively managing, not external threats you're defending against.

Two Fundamentally Different Problems

The solution is recognizing that these require opposite approaches. Shadow AI needs perimeter defense, Enterprise and SaaS agents need governance. Shadow AI is the attacker at your door. Enterprise and SaaS agents are applications you're operating. You defend against external threats differently than you govern internal assets. Getting this distinction right is the difference between mitigating actual risk and engaging in security theater while credentials walk out the door.

The Bottom Line: Stop Defending the Wrong Thing

The agentic AI security conversation has been fundamentally misdirected. The industry debates governance frameworks for enterprise agents that took six months to build while ignoring unmanaged AI infrastructure that developers install in five seconds with production credential access.

This isn't nuanced debate about optimal security architecture, but a categorical misunderstanding of the threat model. Shadow AI, unsanctioned MCP servers from public repositories, is an external threat requiring perimeter defense. Enterprise and SaaS agents are managed assets requiring governance and risk management. These need opposite security strategies.

The bottom line: The agentic AI problem is an identity problem. An agent cannot act without credentials. Shadow AI exploits ambient credentials provisioned for legitimate development work. Enterprise and SaaS agents use explicitly provisioned credentials you control. One is credential exposure to unvetted third-party code. The other is credential management for sanctioned applications.

Modern AI security in a nutshell - elaborate controls for enterprise agents built on unvetted MCP servers installed via npm. (Adapted from XKCD #2347)

Get the taxonomy right, or spend the next year explaining to your board how a developer's productivity tool exfiltrated your production database. The barrier to entry is the threat. The things you control are just assets. Stop defending the wrong thing.