A few years ago, I started Integration Labs around a simple idea: software was becoming more connected, but connecting to the systems businesses actually ran on was still painfully difficult. We built infrastructure that connected products to accounting, commerce, payments, and other business systems through a single API. Over time, that meant we ended up sitting between software and some of the most sensitive systems inside a company, and I got a front-row seat to a problem that would become much more important with AI.
The hard part was no longer simply giving software access. It was deciding what should have access, what it should be allowed to do, and how you maintain control once that software starts acting on its own. With traditional software, this was relatively manageable. Applications were predictable, integrations were built by developers, and permissions were configured upfront. AI changed that model completely.
Employees started connecting ChatGPT to company data. Engineers installed Cursor and Claude Code. Teams began building internal agents. SaaS products quietly added copilots and autonomous workflows. MCP made it dramatically easier to give an AI access to almost anything. Software was no longer just reading from your systems. It could reason about what to do, choose the right tool, access company data, and increasingly take actions on behalf of an employee.
What struck me was that most companies had spent years building systems for identity, access control, security, device management, and software governance, but none of those systems were really designed for this new environment. At the same time, the new generation of AI governance infrastructure was largely being built around the agents developers were creating, rather than the much broader way AI was spreading through an organization.
That is the problem we started Kelasa to solve.
AI adoption is happening faster than governance
Most companies are no longer deciding whether to adopt AI. Their employees already have. They are using ChatGPT, Claude, Gemini, Copilot, Cursor, Codex, and dozens of AI features embedded inside the software they already use. Developers are building internal agents, business teams are automating workflows, and vendors are introducing agents into products that companies already depend on. Increasingly, all of these systems want access to company data, internal tools, and the ability to take actions on behalf of users.
The scale of this shift is becoming difficult to ignore. Netskope found that 59% of enterprise users in the median organization now interact with an AI application every week, up from 34% a year earlier. Conversational AI applications are now used weekly in more than 95% of organizations, while adoption of AI coding applications has risen to 84%. Claude Code alone is being used in 75% of the organizations Netskope observes, and Codex in 58%.
The problem is that enterprises still govern these systems one at a time. Security reviews ChatGPT separately from Claude. IT configures Microsoft Copilot somewhere else. Engineering manages its own agents. Another team builds an MCP server. Someone connects an internal database to a coding agent. Each platform has its own permissions, logs, policies, and administration, while anything outside those approved systems simply becomes shadow AI.
This creates a strange outcome. The companies that want to adopt AI the fastest are often the ones that find it hardest to do safely. Security does not want to give an agent broad access to Salesforce or an internal database. IT does not know which MCP servers employees have connected. Employees do not want to wait weeks for access to an approved tool. Leadership cannot tell which AI products are actually being used, how they are being used, or whether they are creating value.
The answer cannot be another dashboard for every AI provider. Enterprises need a control plane across all of them.
The governance stack was built around the wrong boundary
A lot of the infrastructure being built to govern AI today starts with a developer building an AI application or agent. The assumption is that the company knows the agent exists, controls how it was built, controls the model or gateway it uses, and can route its traffic through a governance layer.
That is an important problem, but it is only one part of enterprise AI.
The fastest-growing surfaces are increasingly the tools employees already work inside: general-purpose AI clients, coding agents, copilots, and AI capabilities embedded into SaaS. Menlo Ventures estimates that more than half of enterprise generative AI spending in 2025 went to the application layer. Within horizontal AI alone, copilots such as ChatGPT Enterprise, Claude for Work, and Microsoft Copilot accounted for $7.2 billion of spending, compared with $750 million for agent platforms. Coding was another $4 billion category.
That distinction matters because you cannot manage this environment by assuming every AI interaction passes through an application your platform team built. An employee can open ChatGPT, install Claude Code, connect an MCP server to Cursor, activate an AI feature inside an existing SaaS product, or authorize a new agent without touching the infrastructure used to govern internally developed AI applications.
The existing enterprise security stack approaches the problem from the other direction. Identity and access management is very good at deciding which employee can access which application, while security products are increasingly able to discover risky AI usage, prevent sensitive information from leaving the company, or block an unapproved application altogether. Those controls are necessary, but they do not answer the question enterprises increasingly need to solve: How do we let employees use more AI, connect it safely to more of the company, and still remain in control?
Blocking cannot be the operating model for enterprise AI. If every new AI tool requires a security exception, an IT ticket, and a bespoke integration before an employee can use it, people will either stop experimenting or find a way around the controls. The better model is to give employees a governed path to AI that is easier than the ungoverned one.
We think that requires a different architecture.
What Kelasa does
Kelasa helps companies Discover, Enable, and Govern AI across the organization. The goal is not to force every team onto one model, one agent framework, or one AI provider. It is to give employees and agents a trusted path to the tools and data they need, while giving IT and Security one place to understand and control what is happening.
Discover means understanding the AI environment that already exists. Which employees are using ChatGPT, Claude, Cursor, Codex, and other AI applications? Which agents have been deployed? Which MCP servers and tools are being connected? Which systems have access to company data? Instead of starting with the assumption that IT already knows what exists, Kelasa starts by building an inventory of how AI is actually being used.
Enable means giving employees a simple way to access approved AI, tools, skills, and company data without turning IT into a bottleneck. Rather than treating every connection as another exception to review, companies can create a trusted path employees can use to discover approved capabilities and connect the AI tools they already prefer to the resources they need.
Govern means defining what happens once those connections exist. Companies can decide who can use an agent, which tools it can access, what actions it can take, which identity it should operate under, and when an approval should be required. Those controls need to exist at the point where AI interacts with the underlying tool or data, rather than depending entirely on the model or agent to follow instructions correctly.
The result is a common control plane across users, agents, tools, and systems. IT can see what is being used, Security can understand what it can access, employees can get access without waiting weeks, and every important action can be attributed back to the user or agent responsible for it.
Most importantly, Kelasa does not require the enterprise to standardize on a single AI platform. Teams should be able to use ChatGPT, Claude, Cursor, Codex, internal agents, third-party agents, or whatever comes next. The applications will change. The models will change. The agent frameworks will change. The governance layer should remain constant.
We think the architecture of enterprise AI will be heterogeneous
Every major AI provider is moving deeper into the enterprise, and all of them will continue building better security and governance controls. They should. Their job is to make their own platforms safe and manageable.
The enterprise has a different problem. It needs to govern the entire environment.
The future is unlikely to be one company running one model with one set of agents. It will be hundreds of AI systems operating across employees, applications, workflows, and infrastructure. Some will be built internally, some will come from vendors, some will operate continuously in the background, and some will act on behalf of employees. Others will have their own identities and permissions. Many of them will appear long before IT knows they exist.
Trying to govern that environment separately inside every AI product will become increasingly difficult. Even if every provider builds excellent controls, the enterprise is still left stitching together identity, permissions, approvals, security, auditability, and visibility across dozens of different systems.
We think there needs to be an independent control plane across them.
That is the role we want Kelasa to play.
Trust creates adoption
One of the biggest misconceptions about AI governance is that it is primarily about stopping people from using AI. We think the opposite is true. Most employees want to use more AI, and most companies want them to. The real bottleneck is whether the organization trusts these systems enough to give them meaningful access.
If Security knows what an agent can access, the company can approve it for more employees. If IT can revoke access centrally, it can allow teams to experiment more freely. If sensitive actions can require approval, agents can be given greater autonomy without handing them unlimited permissions. If employees have an approved way to connect the AI tools they already use to company systems, they have less reason to work around IT entirely.
Good governance should not be the brake on AI adoption. It should be the infrastructure that makes broader adoption possible.
That is why we are building Kelasa: to give companies one place to discover the AI already spreading through their organization, enable employees to use it productively, and govern what happens as AI becomes connected to more of the business.