**Give AI agents a governed way to discover and consume the models, MCP servers, agents, tools, resources, and skills they need — without manually wiring every connection.**
AI agents are becoming more capable. And as they do, they need access to more of the enterprise.
A coding agent might need a model, a GitHub MCP server, and a code review skill. A support agent might need different models, tools, and other agents. A finance agent may need an entirely different set of approved capabilities.
Today, developers often make those connections manually.
That works when you have a few agents connected to a handful of tools. It doesn’t work when dozens of teams are building agents that need access to hundreds or thousands of enterprise capabilities.
**Agents shouldn’t have to be hand-wired to the enterprise.**
We're introducing **Kong AI Registry**, an AI-native discovery layer that gives organizations control over which capabilities are sanctioned while giving agents a self-service way to discover and consume what they need.
API management solved a similar problem for developers.
Instead of asking a platform team every time they needed an API, developers could go to a Developer Portal, discover what was available to them, and start building — within the governance boundaries established by the organization.
Agents need the same construct.
An enterprise may have hundreds of models, MCP servers, agents, tools, resources, and skills available. But an agent shouldn’t need a developer to manually configure every capability it might eventually use.
And it shouldn’t simply be given access to everything.
AI Registry creates a governed discovery layer between the two.
**Humans govern what’s available. Agents discover what they need.**
AI Registry gives organizations a central place to register the infrastructure agents depend on, including:
Each resource can carry the information enterprises need to manage it: ownership, version, approval status, risk, authentication, policies, access, and other metadata.
Instead of every team creating its own list of tools and integrations, approved capabilities become reusable enterprise resources.
That creates a lifecycle for agent infrastructure:
**Register → Approve → Publish → Discover → Consume**
Discovery without governance just creates a different problem.
The engineering organization may have access to coding models, GitHub tools, and engineering agents. Finance may have a different set of approved models and capabilities. Contractors may receive a much narrower selection. Partners may only see resources explicitly published for external consumption.
AI Registry lets organizations create registries for different audiences and publish the appropriate sanctioned resources into each one.
The result isn’t one giant directory of everything an enterprise has.
It’s a set of **governed views of what each audience is allowed to discover**.
And those registries can be exposed through interfaces designed for both machine and human consumption, including MCP, APIs, and portals.
At **build time**, organizations determine the boundaries. Teams register capabilities, establish ownership and metadata, approve them, and decide where they should be published.
At **runtime**, agents operate within those boundaries. They can query the Registry to discover available capabilities and use what they need without requiring developers to pre-wire every possible connection.
That creates an important division of responsibility:
**The organization decides what agents may use. The agent decides what it needs from that sanctioned set.**
Agents get more autonomy without requiring organizations to give up control.
MCP is quickly becoming an important standard for connecting agents with tools. But enterprise agent infrastructure extends beyond MCP servers.
Agents need models for intelligence. They use tools and skills to perform work. They may invoke other agents. They need resources that provide context.
That’s why Kong AI Registry isn’t limited to MCP.
It provides a common discovery surface across the broader set of capabilities that make up an enterprise AI environment.
As that environment grows, this becomes increasingly important. Teams need to know which capabilities already exist, which have been approved, and which ones an agent can actually use.
We’re also introducing Kong Catalog, and the distinction between the two is intentional.
**AI Registry is agent-facing and AI-native.** It provides governed discovery and consumption of models, MCP servers, agents, tools, resources, skills, and other AI capabilities.
**Kong Catalog is human-facing and platform-wide.** It provides a system of record for the assets Kong manages across AI, APIs, and events.
A useful way to think about the difference is:
**Catalog answers: What exists across my enterprise?**
**Registry answers: What is this agent allowed to discover and use?**
An asset can exist in the Catalog without automatically becoming available to agents. Publishing it through a Registry is what makes it discoverable to the appropriate audience.
Together, they provide two complementary views of an increasingly complex enterprise technology estate: one designed for the humans governing it, and one designed for the agents operating within it.
The first generation of enterprise agents has largely been built by explicitly connecting models to a small set of predefined tools, however agents will increasingly need to operate across large, changing ecosystems of models, APIs, MCP servers, tools, skills, data, and other agents.
Manually wiring every relationship doesn’t scale.
The architecture needs to shift from developers deciding in advance what an agent might need and manually connecting it, to the enterprise governing what is available and agents dynamically discovering the capabilities they need to complete the task at hand.
**Govern the capabilities. Publish the boundaries. Let agents discover.**
Kong AI Registry will be generally available at Kong AI Summit 2026.
[Learn More](https://konghq.com/products/mcp-registry)Learn More
**What is an AI agent registry?**
An AI agent registry is a centralized, governed discovery layer that allows enterprises to manage and control which AI capabilities—such as models, MCP servers, and tools—are sanctioned for use. It enables AI agents to autonomously find and connect to the resources they need without requiring developers to manually hard-code every connection.
**Why do enterprises need a discovery layer for AI agents?**
As organizations scale their AI initiatives, manually wiring agents to individual tools and models becomes impossible to maintain. A discovery layer provides self-service capabilities for agents, ensuring they can dynamically find the resources they need to complete tasks while strictly adhering to enterprise governance, security, and access control boundaries.
**How can developers govern which models an AI agent can use?**
Developers and platform teams can govern AI agents by establishing a lifecycle: Register → Approve → Publish → Discover → Consume. Using an AI registry, teams can create specific, role-based views. This means an engineering agent will only discover coding models, while a finance agent will only have access to models and tools approved for financial data.
**What problems does MCP solve vs. an AI registry?**
The Model Context Protocol (MCP) is an important standard that solves the problem of *how* an agent connects to a specific tool or data source. An AI registry solves the problem of *discovery and governance*—determining which MCP servers, models, and tools exist, who owns them, and which agents are actually authorized to use them.
**Does Kong offer an MCP server directory?**
Kong AI Registry functions as much more than a simple MCP server directory. While it does allow you to register, catalog, and discover MCP servers, it acts as a comprehensive AI-native discovery layer that also governs models, agents, tools, resources, and skills across the enterprise.
If you've used KAi before, you'll notice the difference immediately. The enhanced version has deeper access to your Konnect environment and new tools for debugging, analytics, and configuration management: Active tracing and debugging: KAi can now
Every January, the same resolutions show up: eat better, exercise more, finally learn that language, finally figure out that production use case for AI agents (OK, this one isn’t so typical unless you operate in our universe). But if you're respons
MCP ACLs, Claude Code Support, and New Guardrails New providers, smarter routing, stronger guardrails — because AI infrastructure should be as robust as APIs We know that successful AI connectivity programs often start with an intense focus on how
Today, we're open-sourcing Volcano SDK, a TypeScript SDK for building AI agents that combines LLM reasoning with real-world actions through MCP tools. Why Volcano SDK? One reason: because 9 lines of code are faster to write and easier to manage tha
Most AI cost management starts with infrastructure. A provider can tell you that you consumed a certain number of input and output tokens on a particular model. An observability platform can show requests, latency, tokens, and traces. A cloud cost p
Traditional applications generally have well-defined boundaries. They interact with a known set of services using credentials provisioned specifically for those connections. Agents are different. Their value comes from their ability to work across s
When an AI application fails, knowing that an individual model call returned a 200 isn’t enough. You need to know what led to it. Kong stitches the interactions associated with an AI session together, giving developers a view across the sequence of