AI agents are moving from advisory mode to action mode in the enterprise. I joined Craig Smith on the Eye on AI podcast to discuss why most enterprises are still stuck in experimentation, and what governance infrastructure needs to look like before AI agents can be deployed safely in production.

The 100,000 Agent Problem

What is the 100,000 agent problem, and why should IT leaders care about it now?

Agents are going to become essential to how work gets done in enterprises. When I say “agent,” I mean something that actually takes action on behalf of an employee. It does not just suggest what a human should do, it does it. It interacts with the same tools your employees use: Salesforce, email, Slack, Snowflake, whatever your company runs on.

For that to work, you need two things: AI that can connect to those tools, and humans who trust that the AI will use them appropriately. About a year and a half ago, Anthropic introduced a protocol called MCP (the Model Context Protocol) that solved a meaningful portion of the connectivity problem. But MCP is not a security protocol. It is a pipe. It does nothing about trust.

To actually trust an agent to act autonomously, you need to govern it. The agent should only be able to do things directly related to the task it was given. Multiply agents times employees and you can easily reach tens or hundreds of thousands of agents operating inside a single company. That is the 100,000 agent problem.

The Enthusiastic Intern Analogy

You compare AI agents to “enthusiastic interns.” What does that mean for how enterprises should approach deployment?

At their core, AI models are probabilistic systems. You give them a prompt and they return what they believe is the most likely answer. That is fundamentally different from a deterministic API call that does the same thing every time.

An intern will absolutely give you an answer. They will absolutely do something when you tell them to. Whether it is what you intended is another question. The potential blast radius is real.

When you hire an intern, you manage them with appropriate skepticism. You give them work that is not catastrophic if they get it wrong. As they prove themselves, you give them more access and more autonomy. That is how most enterprises are approaching AI right now, whether they realize it or not. They start with glorified search, move to code assistance, then start seeing knowledge workers using agents to actually get things done. The more people see it working, the more they want it.

Why IAM Falls Short

Why doesn’t traditional identity and access management (IAM) cover AI agents?

Identity assumes you have a human, and the human comes with their own governance. I know it is a bad idea to delete Salesforce opportunities. I am allowed to, but I know I should not, and if I do it repeatedly, I will get fired. That is a layer of governance that comes with being a human in a role.

Identity access is also generally over-provisioned, intentionally. Organizations do not want employees running to the Salesforce admin every time they need to do something new. So they give people broad latitude and trust them to use it reasonably.

The problem is you do not want to take authority away from a human just because they are now using AI. But the AI they are using needs a smaller blast radius than the human does. Agents can cause trouble fast. They are much faster than humans at making calls across many systems. You need to dial back what they are capable of doing, at least until you have observed the agent carrying out a specific task and confirmed that its actions are consistent with what it was asked to do. That is a different governance layer than what IAM was built to provide.

AI Governance in Practice

Can you give a concrete example of how the Barndoor governance layer works in practice?

One company we work with set their first policy as: no AI is allowed to post to any Slack channel that starts with #ext. Those are channels that include people from outside the company. Before they had confidence in what AI would say externally, they limited the blast radius to internal channels.

A second policy: no AI is allowed to write any email, Slack message, or other communication that contains what looks like a social security number, phone number, address, or any PII. If an agent attempts that, the attempt is rejected.

Then there are task-specific rules. I have an agent that, after a sales call, goes to my calendar, pulls who was on the call, gets the Zoom transcript, summarizes it, and logs the call in Salesforce. That agent is allowed to create the call log. But I do not allow that specific agent to add new contacts to Salesforce, because sometimes it cannot find the person and creates a duplicate. I would rather it stop and flag me than add noise to our CRM. A different agent I use for conference contact lists has full create permission, because the intent is explicitly to add new people.

Read vs. Write Access

Most out-of-the-box MCP server connections are read-only. Why does that matter?

For an agent to actually be useful, it has to write. An agent that can only read and suggest is just a more expensive search experience.

When you create an MCP server, the person building it chooses which subset of an API’s capabilities to expose to the model. Most APIs can do everything: reads, writes, deletes, drops. Whoever builds the MCP server typically exposes only the safe, read-only subset because there is no governance in place to manage writes.

By using Barndoor, you get MCP servers that include write capabilities, because they come paired with a governance layer that lets you control exactly what an agent is and is not allowed to do. The governance is what makes it safe to enable the capabilities that actually make agents useful.

At enterprise scale, managing governance policies through a user interface is not enough. Barndoor supports policy management via API and JSON, because at a certain point there will be more agents in a company than any team can govern manually. Enterprises can write precise policies and push them programmatically, or build systems that turn agent capabilities on and off based on context. Governance itself becomes automatable.

One more detail worth noting: Barndoor itself is accessible via MCP. Whatever conversational interface a team already uses, they can manage Barndoor policies through it. The control plane fits inside the same ecosystem it governs.

Context Window Exhaustion

What is context window exhaustion, and how does Barndoor Tool IQ address it?

When an AI connects to an MCP server, the first thing it does is load all the tools on that server plus the documentation explaining how to use them. A typical Gmail MCP server might have 40 to 100 different tools, each with significant documentation. That burns a large number of tokens before anything has actually happened.

Add two or three more MCP servers — calendar, Slack, documents, a CRM — and you can exhaust your model’s entire context window before a single action is taken. There is also a quality problem: too many tools creates confusion. You tell the model to look up something in Salesforce, and it goes to Google Drive instead because it is overwhelmed by available options.

What we built is called Tool IQ. Instead of exposing all of your connected tools to the model at once, the model talks to a single MCP: ours. When the model says it is trying to accomplish something, our layer identifies the small subset of tools needed for that specific task and hands only those over. The model does not face a sea of tools. It gets the right tray for the job. That saves tokens, reduces hallucinations, and improves accuracy.

A New Security Vector

AI introduces a new security vector that existing tools were not designed for. What is it?

For most of security’s history, the job was to keep bad actors out or prevent insiders from doing things they are not supposed to do. That remains critically important.

But AI introduces a new vector: someone inside the company, who is allowed to be there, doing something they are allowed to do, with a tool they are allowed to use, and bad things still happen. Not because of malicious intent, but because the agent took an action the human did not fully anticipate, at a speed and scale a human cannot match.

That vector has not been in the realm of IT and security before. You cannot govern it by getting inside the AI’s head any more than you can govern a human that way. The governance has to happen at the boundary: control what goes in and what comes out. That is what Barndoor does.

The Competitive Landscape

How quickly is enterprise adoption accelerating, and where does Barndoor fit in the competitive landscape?

Our deal cadence is increasing. The inflection point happens when people see someone solving a problem they themselves have. That is when experimentation turns into deployment.

I was at a conference last week with about 50 enterprise CIOs and CISOs from very large companies. Many of them already have active IT teams building MCP servers, connecting to both the SaaS tools they use and internal systems. The change from six months ago is striking. This is front of mind for everyone in that room.

On the competitive side: incumbent players in API management, identity, and security are bolting AI governance onto existing infrastructure. In every comparison we have been part of, those solutions do not go far enough. The other category is developer tools where the AI application governs itself internally. No CISO wants hundreds of applications each governing their own AI behavior. Every new application means resetting connections, rules, and governance from scratch. A centralized control plane is the only approach that scales.

My argument to security and IT leaders: no one should trust AI companies to govern themselves. The incentives to ship fast are fundamentally at odds with the incentives around governance. A dedicated control plane, independent of the AI providers it governs, is the architecture that resolves that conflict.

Why 2026 Is Different

Why is 2026 the inflection point for enterprise agentic AI?

The adoption curve has followed a predictable path. Coders adopted AI first, because having experts review and fix your work is already how software development works. Then AI became useful for knowledge workers in an advisory capacity. Now enterprises are starting to see agentic AI in actual production, and the pattern-matching instinct takes over: the more people see it working, the more they want it. I estimate less than one percent of large enterprises have agents running in production today. But the shift from experimentation to deployment is underway. The organizations building governance infrastructure now are the ones positioned to scale when adoption accelerates.

Listen to the full episode on Eye on AI — available on Apple Podcasts and YouTube.