Everyone is preparing for a world of AI agents. Developers are building them, SaaS companies are shipping them, and every major AI platform is adding ways for agents to connect to company systems and take actions. As these systems move into production, a new category of infrastructure is emerging around them: identity, permissions, observability, policy enforcement, audit trails, and the ability to revoke access when something goes wrong.
All of that is necessary, but I think much of the market is drawing the boundary in the wrong place.
Most AI governance infrastructure today starts with an agent that a developer has built. The enterprise knows the agent exists, controls the application or runtime, and can place infrastructure around it before it reaches production. From there, the governance problem is relatively well defined: identify the agent, scope its credentials, inspect its tool calls, enforce policy, and maintain an audit trail.
The problem is that this is not how most AI is entering the enterprise. AI is increasingly arriving through employees using ChatGPT and Claude for research and analysis, Cursor and Claude Code inside engineering environments, Copilot and Gemini inside productivity suites, and AI features that are being added to the SaaS applications companies already use. Increasingly, an employee can also connect one of these tools to an MCP server and give it access to another part of the company without ever going through the infrastructure used to deploy an internally built agent.
The agent your platform team deployed is part of the problem. It is not the boundary of the problem.
Look at where AI adoption is actually happening
The numbers are beginning to make this distinction clearer.
According to Gallup's July 2026 workplace research, 52% of U.S. employees now use AI in their role at least occasionally. Among employees who use AI, the most common applications are writing and editing, search and research, and general assistance or problem-solving. Coding assistance and workflow automation are each used by 16% of AI users. Enterprise AI adoption is already broad-based knowledge work, not primarily a developer deploying an autonomous agent into production.
Enterprise spending points in the same direction. Menlo Ventures estimates that companies spent roughly $19 billion on the generative AI application layer in 2025. Within horizontal AI, general-purpose copilots such as ChatGPT Enterprise, Claude for Work, and Microsoft Copilot accounted for an estimated $7.2 billion of spending, compared with roughly $750 million for horizontal agent platforms. Coding tools represented another estimated $4 billion category.
The surface area is also much larger than the obvious standalone AI products. Netskope's 2025 research found that 98% of organizations in its dataset had employees accessing applications with generative AI features, with roughly 75% of users interacting with those AI-enabled SaaS products. Its 2026 AI Index found that 44% of enterprise users were interacting with at least one AI application every week, while the average enterprise in its telemetry saw employees accessing around 60 different AI applications in a single week.
That is a very different governance problem from managing a collection of internally developed agents.
It means the AI estate of a company is increasingly created from the bottom up. Employees choose tools, developers install coding agents, SaaS vendors introduce new capabilities, and teams connect new data sources. AI functionality can appear inside an application that IT approved years before that application contained an agent at all.
The enterprise does not start with a clean inventory and then deploy AI. AI gets deployed, and the inventory has to catch up.
The existing categories each solve part of the problem
Developer-focused agent governance solves an important problem. If you are building fifty internal agents, you need identities, credentials, permissions, tool policies, deployment controls, observability, and auditability. A framework may help you build the agent, but something else has to govern what happens when that agent begins interacting with production systems.
Traditional identity infrastructure solves another part of the problem. It knows which employee belongs to Finance, which belongs to Sales, and what applications each of them should be able to access. SSO, SCIM, RBAC, PAM, and the broader identity stack remain critical, but they were designed primarily around people accessing applications, not AI systems dynamically choosing tools and acting across them.
AI security products solve another part. They can discover applications, inspect prompts, detect sensitive data, classify risk, and block tools that violate company policy. Those controls matter, but they mostly answer the security question: how do we prevent something bad from happening?
The question enterprises increasingly need to answer is broader:
How do we help every employee use more AI, connect it safely to more of the company, and still remain in control?
Blocking alone does not answer that question, and neither does governing only the agents engineering has deployed.
The employee does not particularly care whether the capability they need lives in ChatGPT, Claude, Cursor, an internal agent, or a SaaS application. They want to accomplish a task. If the approved path takes three weeks and the unapproved path takes three minutes, people will inevitably find ways around the approved path.
Netskope's 2026 AI Index gives a useful signal here. It found that 12% of enterprise users in its dataset were bypassing approved AI tools and using personal AI applications or personal instances each week. Their interpretation is important: shadow AI is not always an employee deliberately behaving recklessly. Often, it is an employee trying to get work done while the official stack moves too slowly.
This is why we think AI governance needs to become an enablement problem, not just a security problem.
The control plane has to sit above the AI application
An enterprise AI control plane cannot assume that it owns the model, the application, or the agent runtime. It has to work across them.
A marketing employee may work in ChatGPT. An engineer may live in Cursor and Claude Code. Another team may build an agent internally. Finance may use AI embedded inside an existing SaaS product. Six months later, all of those tools may change.
The governance architecture therefore has to be more durable than the application layer. The models will change, the interfaces will change, and the agent frameworks will change, but the enterprise will still need to answer the same questions: what AI is being used, who is using it, what it can access, which identity it operates under, what actions it can take, and who is accountable when it does.
This is the idea behind Kelasa.
Kelasa is a control plane to Discover, Enable, and Govern AI across the organization.
Discover starts with reality rather than the approved inventory. Which AI applications are employees actually using? Which coding agents are installed? Which MCP servers are connected? Which agents have been deployed? Which AI-enabled applications are interacting with company data? Before an organization can govern its AI environment, it needs to understand what that environment actually contains.
Enable is the piece we think the security conversation often misses. Employees need a governed path to AI that is easier than the ungoverned path. That means giving them a place to find approved AI tools, agents, skills, and company integrations, while making it simple to connect those capabilities to the resources they are allowed to use. The goal is not to turn IT into the approval queue for every new AI workflow. It is to define the boundaries once and let employees move quickly inside them.
Govern begins when AI becomes connected to the company. Which employee is invoking it? Which agent is acting? What system is it trying to reach? Which identity should be used? Which tools should be available? Does this action require approval? What happened after the action was taken? Policy needs to follow the interaction rather than being trapped inside whichever AI client happened to initiate it.
The result should be a common governance layer across ChatGPT, Claude, Cursor, Codex, internally built agents, third-party agents, MCP servers, and whatever AI applications come next.
Discovery without enablement becomes whack-a-mole
There is another reason we think these three functions belong together.
Security teams are going to get much better at discovering AI. Browsers, endpoints, identity systems, network security products, and SaaS management platforms will increasingly tell companies which AI applications employees are using. That visibility matters, but visibility alone risks creating an endless cycle of discovery, review, and blocking.
There will always be another application.
Netskope was tracking 317 distinct generative AI applications in its 2025 report. By 2026, its telemetry showed the average enterprise accessing roughly 60 different AI applications in a single week.
You cannot ticket your way through that.
The long-term answer is not to perfectly predict which AI products employees will want. It is to build an architecture where employees can adopt new capabilities without forcing the company to rebuild governance around every new interface.
That is why discovery, enablement, and governance have to converge. Discovery tells you what exists. Governance defines the boundaries. Enablement gives employees a reason to stay inside them.
AI is becoming part of the workforce
The most important change may be that the distinction between an AI "tool" and an AI "agent" is already starting to disappear.
Microsoft's 2026 Work Trend Index describes workers moving between asking AI questions, collaborating with it, and delegating larger pieces of work to agents. Among the 20,000 AI users Microsoft surveyed, roughly 16% met its definition of "Frontier Professionals," people who are already using AI in more advanced ways that include delegating multi-step workflows and working with agents.
Research on the adoption of OpenAI Codex points in the same direction. A 2026 study of Codex usage found that active users grew more than fivefold during the first half of 2026, with adoption increasingly extending beyond traditional software-development workflows. The researchers also found that more than 10% of users managed three or more concurrent Codex agents at some point during a week.
This suggests that the future enterprise AI environment will not divide neatly into "employees using AI" and "developers building agents." Employees themselves will increasingly create, configure, delegate to, and supervise agents.
At that point, governing agents without governing employee AI stops making much sense. The employee, the agent, the tools it can access, the identity it operates under, and the policies governing its actions become part of the same system.
The goal is not control. It is adoption.
The instinct of enterprise security is understandably to reduce the number of things that can go wrong. AI creates an uncomfortable amount of uncertainty because new applications appear constantly, models are non-deterministic, employees can connect them to sensitive systems, and agents can increasingly take actions rather than simply generate text.
But the companies that win with AI will not be the ones that become best at saying no. They will be the ones that figure out how to safely say yes more often.
Gallup's research shows that employees using AI across more parts of their work are more likely to report substantial productivity improvements. Microsoft's research similarly found that 66% of the AI users it surveyed said AI allowed them to spend more time on higher-value work.
The opportunity, therefore, is not to reduce AI usage. It is to increase trusted AI usage.
That requires visibility without turning discovery into an endless blocking exercise, policy without creating another layer of bureaucracy, and security controls that make the approved path easier rather than harder.
We are building Kelasa because we think this becomes a new layer of enterprise infrastructure: not an agent gateway that assumes you built every agent, not another security product whose primary action is block, and not another administration console tied to a single AI provider.
A control plane for the AI that is actually entering the enterprise.
Discover it. Enable it. Govern it.